Advanced field extractor with modification of an extracted field

ABSTRACT

The technology disclosed relates to formulating and refining field extraction rules that are used at query time on raw data with a late-binding schema. The field extraction rules identify portions of the raw data, as well as their data types and hierarchical relationships. These extraction rules are executed against very large data sets not organized into relational structures that have not been processed by standard extraction or transformation methods. By using sample events, a focus on primary and secondary example events help formulate either a single extraction rule spanning multiple data formats, or multiple rules directed to distinct formats. Selection tools mark up the example events to indicate positive examples for the extraction rules, and to identify negative examples to avoid mistaken value selection. The extraction rules can be saved for query-time use, and can be incorporated into a data model for sets and subsets of event data.

CROSS-REFERENCES TO RELATED APPLICATIONS

This application is a continuation-in-part of prior U.S. applicationSer. No. 14/266,839, filed 1 May 2014, entitled “Real Time Indication OfPreviously Extracted Data Fields For Regular Expressions,” by R. DavidCarasso, Micah James Delfino and Johnvey Hwang, which application is acontinuation of prior U.S. application Ser. No. 13/748,391, filed 23Jan. 2013, entitled “REAL TIME INDICATION OF PREVIOUSLY EXTRACTED DATAFIELDS FOR REGULAR EXPRESSIONS,” by R. David Carasso, Micah JamesDelfino and Johnvey Hwang, now U.S. Pat. No. 8,751,963, issued 10 Jun.2014, both of which applications are incorporated herein by reference intheir entirety.

This application is also continuation-in-part of prior U.S. applicationSer. No. 14/168,888, filed 30 Jan. 2014, entitled “SAMPLING OF EVENTS TOUSE FOR DEVELOPING A FIELD-EXTRACTION RULE FOR A FIELD TO USE IN EVENTSEARCHING,” by R. David Carasso and Micah James Delfino, whichapplication is a continuation of prior U.S. application Ser. No.13/747,153, filed 22 Jan. 2013, entitled “VARIABLE REPRESENTATIVESAMPLING UNDER RESOURCE CONSTRAINTS,” by R. David Carasso and MicahJames Delfino, now U.S. Pat. No. 8,751,499, issued 10 Jun. 2014, both ofwhich applications are incorporated herein by reference in theirentirety.

This application is also continuation-in-part of prior U.S. applicationSer. No. 14/169,268, filed 31 Jan. 2014, entitled “PREVIEWING ANEXTRACTION RULE FOR A FIELD IN EXEMPLARY EVENTS AND MODIFYING THE RULETHROUGH COUNTER-EXAMPLE,” by R. David Carasso, Micah James Delfino andJohnvey Hwang, which application is a continuation of prior U.S.application Ser. No. 13/748,313, filed 23 Jan. 2013, entitled “REAL TIMEDISPLAY OF DATA FIELD VALUES BASED ON MANUAL EDITING OF REGULAREXPRESSIONS,” by R. David Carasso, Micah James Delfino and JohnveyHwang, now U.S. Pat. No. 8,682,906, issued 25 Mar. 2014, both of whichapplications are incorporated herein by reference in their entirety.

This application is also continuation-in-part of prior U.S. applicationSer. No. 13/747,177, filed 22 Jan. 2013, entitled “INTERFACE FORMANAGING SPLITTABLE TIMESTAMPS ACROSS EVENT RECORDS,” by R. DavidCarasso and Micah James Delfino, which application is incorporatedherein by reference in its entirety.

This application is also continuation-in-part of prior U.S. applicationSer. No. 14/067,203, filed 30 Oct. 2013, entitled “GENERATION OF A DATAMODEL FOR SEARCHING MACHINE DATA,” by Alice Emily Neels, ArchanaSulochana Ganapathi, Marc Vincent Robichaud, Stephen Phillip Sorkin andSteve Yu Zhang, which application is a continuation of prior U.S.application Ser. No. 13/607,117, filed 7 Sep. 2012, entitled “DATA MODELFOR MACHINE DATA FOR SEMANTIC SEARCH,” by Alice Emily Neels, ArchanaSulochana Ganapathi, Marc Vincent Robichaud, Stephen Phillip Sorkin andSteve Yu Zhang, now U.S. Pat. No. 8,788,525, issued 22 Jul. 2014, bothof which applications are incorporated herein by reference in theirentirety.

TECHNICAL FIELD

The technology disclosed relates to formulating and refining fieldextraction rules. A primary use of these field extraction rules is atquery time, as part of a late binding schema or in a data model.

BACKGROUND

An increasing amount of data is generated by machines, as the so-calledInternet of Things gains momentum. Human-generated content was the focusof the original Internet. Now many types of machines are online andconnected. These machines generate many types of data, most of which isnever viewed by a human. A single machine can generate many distincttypes of data.

It is challenging to make sense of machine generated data. One of thechallenges is developing schemas and extraction rules. Often, the formatof the data being collected has not been determined or formallydescribed when data collection begins. Issues to be addressed may not beappreciated when the data is collected. This makes schema and extractionrule development a moving target.

SUMMARY

The technology disclosed relates to formulating and refining fieldextraction rules. A primary use of these field extraction rules is atquery time, as part of a late binding schema or in a data model.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 presents a block diagram of an event-processing system inaccordance with the disclosed embodiments.

FIG. 2 presents a flowchart illustrating how indexers process, index,and store data received from forwarders in accordance with the disclosedembodiments.

FIG. 3 presents a flowchart illustrating how a search head and indexersperform a search query in accordance with the disclosed embodiments.

FIG. 4 presents a block diagram of a system for processing searchrequests that uses extraction rules for field values in accordance withthe disclosed embodiments.

FIG. 5 illustrates an exemplary search query received from a client andexecuted by search peers in accordance with the disclosed embodiments.

FIG. 6A illustrates a search screen in accordance with the disclosedembodiments.

FIG. 6B illustrates a data summary dialog that enables a user to selectvarious data sources in accordance with the disclosed embodiments.

FIG. 7A illustrates a key indicators view in accordance with thedisclosed embodiments.

FIG. 7B illustrates an incident review dashboard in accordance with thedisclosed embodiments.

FIG. 7C illustrates a proactive monitoring tree in accordance with thedisclosed embodiments.

FIG. 7D illustrates a screen displaying both log data and performancedata in accordance with the disclosed embodiments.

FIG. 8 illustrates a portion of a wizard that guides a user through astructured sequence of steps to produce extraction rules.

FIG. 9 illustrates a portion of a GUI that features one example eventthat has been marked up to indicate fields to extract and a preview ofresults of applying an extraction rule.

FIG. 10 illustrates a portion of a GUI that details extraction resultsfor a particular field.

FIG. 11 illustrates a portion of a GUI with a key-value filter appliedto events and sample events that satisfy the filter

FIG. 12A and FIG. 12B illustrate pull down menu implementations thatselect among sampling strategies to determine events to analyze.

FIG. 13A and FIG. 13B illustrate portions of a GUI that presentssecondary examples of events to mark up during extraction rulegeneration.

FIG. 14 illustrates a portion of a GUI that previews results of applyingan extraction rule formulated using multiple example events and positiveexamples of values to select.

FIG. 15A and FIG. 15B illustrate how one selected field can anchorselection of an additional field.

FIG. 16 illustrates a portion of a GUI used to require that a particularvalue be found in an event for an extraction rule to apply to an event.This can be particularly useful when the events appear in multipledistinct formats that require multiple extraction rules to correlatedata among the formats.

FIG. 17 illustrates three extensions of field extraction rules:concatenate, trim and extract-from-extraction.

FIG. 18A illustrates a portion of a validation GUI.

FIG. 18B illustrates formatting an example event to indicate that atoken in the example event has been registered as a negative example.

FIG. 19 illustrates saving an extraction rule for subsequentapplication.

FIG. 20 illustrates one embodiment of an architecture for use inmanaging variable data selection of a representative data subset from alarger dataset

FIG. 21 illustrates a logical flow diagram generally showing oneembodiment of a process for enabling real time display of event recordsand extracted values based on manual editing of a data field extractionrule.

FIG. 22 illustrates a logical flow diagram generally showing oneembodiment of a process for enabling the filtering of event recordsbased on a selected extracted value.

FIG. 23 can include parameter/criteria selections including data sourcetype, data source, subset type, maximum records, record sample, as wellas selections that enable post-processing, such as save selection, shareselection, and analyze selection.

FIG. 24 shows a flow chart of one embodiment of a process usable tomanage variable representative sampling of data as a subset from alarger dataset that includes unstructured data.

FIG. 25 shows a flow chart of one embodiment of a process for analyzingdata.

FIG. 26 illustrates one non-limiting, non-exhaustive example embodimentof a graphical user interface (GUI) usable to manage selection of arepresentative data subset from a larger dataset.

FIG. 27 illustrates a logical flow diagram generally showing oneembodiment of a process for displaying event records that emphasizesfields based on previously provided extraction rules.

FIG. 28 illustrates a logical flow diagram generally showing oneembodiment of a process for displaying previously provided extractionrules associated with a selected portion of an event record.

FIG. 29 illustrates a logical flow diagram generally showing oneembodiment of a process for displaying statistics of extracted eventsbased on an extraction rule.

FIGS. 30A, 30B, and 30C illustrate a non-exhaustive example of a usecase of an embodiment of graphical user interface that may be employedto enable a user to create extraction rule and to obtain real timedisplay of extracted values.

FIG. 31 illustrates a non-exhaustive example of a use case of anembodiment of graphical user interface that may be employed to displayevent records with an emphasis of fields defined by previously providedextraction rules.

FIGS. 32A and 32B illustrate non-exhaustive examples of a use case ofembodiments of a graphical user interface to display extraction rulesand/or fields associated with a selected portion of an event record.

FIGS. 33A and 33B illustrate a use case example of a real time displayof an event record based on manual editing of an extraction rule.

FIG. 34 illustrates a logical flow diagram generally showing oneembodiment of an overview process for identifying one or more locationswithin an event record with splitable timestamp information.

FIGS. 35A, 35B, and 35C illustrate various non-limiting, non-exhaustivegraphical user interfaces usable for identifying/selecting one or morelocations within event records with splitable timestamp information.

DETAILED DESCRIPTION

This Detailed Description is organized into four sections: an Overviewof the Technology Disclosed, a Common Disclosure Section, a TechnologyDisclosed section, and a section containing disclosure from PriorityApplications.

The Overview of the Technology Disclosed briefly introduces some of thetechnology disclosed.

The Common Disclosure Section provides general disclosures of Splunk'sdatabase technology, which handle portions of raw data as events,especially large volumes of machine generated data.

The Technology Disclosed section explains the technology in FIGS. 8-19.

The Priority Applications section repeats selected disclosure frompriority applications.

Overview of the Technology Disclosed

The technology disclosed relates to formulating and refining fieldextraction rules. A primary use of these field extraction rules is atquery time, as part of a late binding schema. Use of a field extractionrule at query time instead of ingestion time is a major innovation, aparadigm shift from traditional relational data bases in which inputdata is transformed for storage in fields of a data object or of a tablerow. When a field extraction rule is applied to events, values can beextracted from portions of raw data in the events. The field extractionrule identifies a particular portion of the raw data from which thevalue is extracted. As part of a data model, the field extraction rulecan also identify the data type of the extracted value.

In some environments, raw machine data can be collected from manysources before extraction rules or late binding schemas are formulatedto extract values from the data. Extremely large data sets can result,because machines can be configured to generate very detailed logs.Unlike a traditional database environment organized into tables withrows and columns, this machine data can be collected in a raw formatfrom data sets generated by machines and held for analysis if needed.The data held in the data store need not be extracted or transformedinto fielded data objects. Analysis tools and a wizard can allow a userwithout extensive programming experience or training to create one ormore extraction rules that deliver data values from events in machinedata.

Tools improve formulation and refinement of extraction rules. Inparticular, series of analytical interfaces is described that can becombined into a wizard that guides a user through selecting a sourcetype, selecting primary and additional example events, selecting fieldsto extract from the events, validating field extraction results andsaving completed extraction rules for later use. The wizard can beparticularly useful with complex data sets that can include manydistinct formats of data.

Use of example events and multiple example events is described. Focus ona primary example event and secondary example events accommodatesformulation of either a single rule that spans multiple distinct formatsof data or multiple rules directed to distinct formats, in a divide andconquer approach. Sampling tools present selected event samples fromwhich primary and secondary example events can be selected. Selectiontools mark up the example events to indicate positive examples of whatthe extraction rules should extract. The tools also support namingfields into which extracted values are organized. A dialog window is onekind of tool used to name fields. Analysis tools reveal how extractionrules behave when applied to various samples of events, which can bere-specified and resampled. Specific values that should or should not beextracted by rule can be identified using the analysis tools. Theextraction rules are generated taking into account both positive andnegative examples. Validation tools allow identification of negativeexamples and refinement of extraction rules to avoid mistaken valueselection. A wizard can combine these types of tools in a guided processthat generates extraction rules.

Extraction rules are saved for query time use. Extraction rules can beincorporated into a data model for sets and subsets of event data. Alate binding schema can be produced from one or more extraction rules.Extraction rules formulated by users can be combined with automaticallygenerated extraction rules, such as rules that recognize key-value pairsin the machine data.

Common Disclosure Section

Modern data centers often comprise thousands of host computer systemsthat operate collectively to service requests from even larger numbersof remote clients. During operation, these data centers generatesignificant volumes of performance data and diagnostic information thatcan be analyzed to quickly diagnose performance problems. In order toreduce the size of this performance data, the data is typicallypre-processed prior to being stored based on anticipated data-analysisneeds. For example, pre-specified data items can be extracted from theperformance data and stored in a database to facilitate efficientretrieval and analysis at search time. However, the rest of theperformance data is not saved and is essentially discarded duringpre-processing. As storage capacity becomes progressively cheaper andmore plentiful, there are fewer incentives to discard this performancedata and many reasons to keep it.

This plentiful storage capacity is presently making it feasible to storemassive quantities of minimally processed performance data at “ingestiontime” for later retrieval and analysis at “search time.” Note thatperforming the analysis operations at search time provides greaterflexibility because it enables an analyst to search all of theperformance data, instead of searching pre-specified data items thatwere stored at ingestion time. This enables the analyst to investigatedifferent aspects of the performance data instead of being confined tothe pre-specified set of data items that were selected at ingestiontime.

However, analyzing massive quantities of heterogeneous performance dataat search time can be a challenging task. A data center may generateheterogeneous performance data from thousands of different components,which can collectively generate tremendous volumes of performance datathat can be time-consuming to analyze. For example, this performancedata can include data from system logs, network packet data, sensordata, and data generated by various applications. Also, the unstructurednature of much of this performance data can pose additional challengesbecause of the difficulty of applying semantic meaning to unstructureddata, and the difficulty of indexing and querying unstructured datausing traditional database systems.

These challenges can be addressed by using an event-based system, suchas the SPLUNK® ENTERPRISE system produced by Splunk Inc. of SanFrancisco, Calif., to store and process performance data. The SPLUNK®ENTERPRISE system is the leading platform for providing real-timeoperational intelligence that enables organizations to collect, index,and harness machine-generated data from various websites, applications,servers, networks, and mobile devices that power their businesses. TheSPLUNK® ENTERPRISE system is particularly useful for analyzingunstructured performance data, which is commonly found in system logfiles. Although many of the techniques described herein are explainedwith reference to the SPLUNK® ENTERPRISE system, the techniques are alsoapplicable to other types of data server systems.

In the SPLUNK® ENTERPRISE system, performance data is stored as“events,” wherein each event comprises a collection of performance dataand/or diagnostic information that is generated by a computer system andis correlated with a specific point in time. Events can be derived from“time series data,” wherein time series data comprises a sequence ofdata points (e.g., performance measurements from a computer system) thatare associated with successive points in time and are typically spacedat uniform time intervals. Events can also be derived from “structured”or “unstructured” data. Structured data has a predefined format, whereinspecific data items with specific data formats reside at predefinedlocations in the data. For example, structured data can include dataitems stored in fields in a database table. In contrast, unstructureddata does not have a predefined format. This means that unstructureddata can comprise various data items having different data types thatcan reside at different locations. For example, when the data source isan operating system log, an event can include one or more lines from theoperating system log containing raw data that includes different typesof performance and diagnostic information associated with a specificpoint in time. Examples of data sources from which an event may bederived include, but are not limited to: web servers; applicationservers; databases; firewalls; routers; operating systems; and softwareapplications that execute on computer systems, mobile devices, andsensors. The data generated by such data sources can be produced invarious forms including, for example and without limitation, server logfiles, activity log files, configuration files, messages, network packetdata, performance measurements and sensor measurements. An eventtypically includes a timestamp that may be derived from the raw data inthe event, or may be determined through interpolation between temporallyproximate events having known timestamps.

The SPLUNK® ENTERPRISE system also facilitates using a flexible schemato specify how to extract information from the event data, wherein theflexible schema may be developed and redefined as needed. Note that aflexible schema may be applied to event data “on the fly,” when it isneeded (e.g., at search time), rather than at ingestion time of the dataas in traditional database systems. Because the schema is not applied toevent data until it is needed (e.g., at search time), it is referred toas a “late-binding schema.”

During operation, the SPLUNK® ENTERPRISE system starts with raw data,which can include unstructured data, machine data, performancemeasurements or other time-series data, such as data obtained fromweblogs, syslogs, or sensor readings. It divides this raw data into“portions,” and optionally transforms the data to produce timestampedevents. The system stores the timestamped events in a data store, andenables a user to run queries against the data store to retrieve eventsthat meet specified criteria, such as containing certain keywords orhaving specific values in defined fields. Note that the term “field”refers to a location in the event data containing a value for a specificdata item.

As noted above, the SPLUNK® ENTERPRISE system facilitates using alate-binding schema while performing queries on events. A late-bindingschema specifies “extraction rules” that are applied to data in theevents to extract values for specific fields. More specifically, theextraction rules for a field can include one or more instructions thatspecify how to extract a value for the field from the event data. Anextraction rule can generally include any type of instruction forextracting values from data in events. In some cases, an extraction rulecomprises a regular expression, in which case the rule is referred to asa “regex rule.”

In contrast to a conventional schema for a database system, alate-binding schema is not defined at data ingestion time. Instead, thelate-binding schema can be developed on an ongoing basis until the timea query is actually executed. This means that extraction rules for thefields in a query may be provided in the query itself, or may be locatedduring execution of the query. Hence, as an analyst learns more aboutthe data in the events, the analyst can continue to refine thelate-binding schema by adding new fields, deleting fields, or changingthe field extraction rules until the next time the schema is used by aquery. Because the SPLUNK® ENTERPRISE system maintains the underlyingraw data and provides a late-binding schema for searching the raw data,it enables an analyst to investigate questions that arise as the analystlearns more about the events.

In the SPLUNK® ENTERPRISE system, a field extractor may be configured toautomatically generate extraction rules for certain fields in the eventswhen the events are being created, indexed, or stored, or possibly at alater time. Alternatively, a user may manually define extraction rulesfor fields using a variety of techniques.

Also, a number of “default fields” that specify metadata about theevents rather than data in the events themselves can be createdautomatically. For example, such default fields can specify: a timestampfor the event data; a host from which the event data originated; asource of the event data; and a source type for the event data. Thesedefault fields may be determined automatically when the events arecreated, indexed or stored.

In some embodiments, a common field name may be used to reference two ormore fields containing equivalent data items, even though the fields maybe associated with different types of events that possibly havedifferent data formats and different extraction rules. By enabling acommon field name to be used to identify equivalent fields fromdifferent types of events generated by different data sources, thesystem facilitates use of a “common information model” (CIM) across thedifferent data sources.

1. Data Server System

FIG. 1 presents a block diagram of an exemplary event-processing system100, similar to the SPLUNK® ENTERPRISE system. System 100 includes oneor more forwarders 101 that collect data obtained from a variety ofdifferent data sources 105, and one or more indexers 102 that store,process, and/or perform operations on this data, wherein each indexeroperates on data contained in a specific data store 103. Theseforwarders and indexers can comprise separate computer systems in a datacenter, or may alternatively comprise separate processes executing onvarious computer systems in a data center.

During operation, the forwarders 101 identify which indexers 102 willreceive the collected data and then forward the data to the identifiedindexers. Forwarders 101 can also perform operations to strip outextraneous data and detect timestamps in the data. The forwarders nextdetermine which indexers 102 will receive each data item and thenforward the data items to the determined indexers 102.

Note that distributing data across different indexers facilitatesparallel processing. This parallel processing can take place at dataingestion time, because multiple indexers can process the incoming datain parallel. The parallel processing can also take place at search time,because multiple indexers can search through the data in parallel.

System 100 and the processes described below with respect to FIGS. 1-5are further described in “Exploring Splunk Search Processing Language(SPL) Primer and Cookbook” by David Carasso, CITO Research, 2012, and in“Optimizing Data Analysis With a Semi-Structured Time Series Database”by Ledion Bitincka, Archana Ganapathi, Stephen Sorkin, and Steve Zhang,SLAML, 2010, each of which is hereby incorporated herein by reference inits entirety for all purposes.

2. Data Ingestion

FIG. 2 presents a flowchart illustrating how an indexer processes,indexes, and stores data received from forwarders in accordance with thedisclosed embodiments. At block 201, the indexer receives the data fromthe forwarder. Next, at block 202, the indexer apportions the data intoevents. Note that the data can include lines of text that are separatedby carriage returns or line breaks and an event may include one or moreof these lines. During the apportioning process, the indexer can useheuristic rules to automatically determine the boundaries of the events,which for example coincide with line boundaries. These heuristic rulesmay be determined based on the source of the data, wherein the indexercan be explicitly informed about the source of the data or can infer thesource of the data by examining the data. These heuristic rules caninclude regular expression-based rules or delimiter-based rules fordetermining event boundaries, wherein the event boundaries may beindicated by predefined characters or character strings. Thesepredefined characters may include punctuation marks or other specialcharacters including, for example, carriage returns, tabs, spaces orline breaks. In some cases, a user can fine-tune or configure the rulesthat the indexers use to determine event boundaries in order to adaptthe rules to the user's specific requirements.

Next, the indexer determines a timestamp for each event at block 203. Asmentioned above, these timestamps can be determined by extracting thetime directly from data in the event, or by interpolating the time basedon timestamps from temporally proximate events. In some cases, atimestamp can be determined based on the time the data was received orgenerated. The indexer subsequently associates the determined timestampwith each event at block 204, for example by storing the timestamp asmetadata for each event.

Then, the system can apply transformations to data to be included inevents at block 205. For log data, such transformations can includeremoving a portion of an event (e.g., a portion used to define eventboundaries, extraneous text, characters, etc.) or removing redundantportions of an event. Note that a user can specify portions to beremoved using a regular expression or any other possible technique.

Next, a keyword index can optionally be generated to facilitate fastkeyword searching for events. To build a keyword index, the indexerfirst identifies a set of keywords in block 206. Then, at block 207 theindexer includes the identified keywords in an index, which associateseach stored keyword with references to events containing that keyword(or to locations within events where that keyword is located). When anindexer subsequently receives a keyword-based query, the indexer canaccess the keyword index to quickly identify events containing thekeyword.

In some embodiments, the keyword index may include entries forname-value pairs found in events, wherein a name-value pair can includea pair of keywords connected by a symbol, such as an equals sign orcolon. In this way, events containing these name-value pairs can bequickly located. In some embodiments, fields can automatically begenerated for some or all of the name-value pairs at the time ofindexing. For example, if the string “dest=10.0.1.2” is found in anevent, a field named “dest” may be created for the event, and assigned avalue of “10.0.1.2.”

Finally, the indexer stores the events in a data store at block 208,wherein a timestamp can be stored with each event to facilitatesearching for events based on a time range. In some cases, the storedevents are organized into a plurality of buckets, wherein each bucketstores events associated with a specific time range. This not onlyimproves time-based searches, but it also allows events with recenttimestamps that may have a higher likelihood of being accessed to bestored in faster memory to facilitate faster retrieval. For example, abucket containing the most recent events can be stored as flash memoryinstead of on hard disk.

Each indexer 102 is responsible for storing and searching a subset ofthe events contained in a corresponding data store 103. By distributingevents among the indexers and data stores, the indexers can analyzeevents for a query in parallel, for example using map-reduce techniques,wherein each indexer returns partial responses for a subset of events toa search head that combines the results to produce an answer for thequery. By storing events in buckets for specific time ranges, an indexermay further optimize searching by looking only in buckets for timeranges that are relevant to a query.

Moreover, events and buckets can also be replicated across differentindexers and data stores to facilitate high availability and disasterrecovery as is described in U.S. patent application Ser. No. 14/266,812filed on 30 Apr. 2014, and in U.S. application patent Ser. No.14/266,817 also filed on 30 Apr. 2014.

3. Data Modeling

A data model presents subsets of events in the data store andlate-binding schema extraction rules applicable to the respectivesubsets. Objects that reference the subsets can be arranged in ahierarchical manner, so that child subsets of events are proper subsetsof their parents. A user iteratively applies a model development tool toprepare a query that defines a subset of events and assigns an objectname to that subset. A child subset is created by further limiting aquery that generates a parent subset. A late-binding schema orsub-schema of field extraction rules is associated with each object orsubset in the data model. Data definitions in associated schemas orsub-schemas can be taken from the common information model or can bedevised for a particular sub-schema and optionally added to the CIM.Child objects inherit fields from parents and can include fields notpresent in parents. A model developer can expose a subset of the fieldsthat are available with a data subset. Selecting a limited set of fieldsand extraction rules can simplify and focus the data model, whileallowing a user flexibility to explore the data subset. Development of adata model is further explained in U.S. patent application Ser. No.14/067,203 filed on 30 Oct. 2013. See, also, Knowledge Manager Manual,Build a Data Model, Splunk Enterprise 6.1.3 pp. 150-204 (Aug. 25, 2014).

A data model also can include reports. One or more report formats can beassociated with a particular data model and be made available to runagainst the data model.

Data models feed into the PIVOT™ report generation interface. Thisreport generator supports drag-and-drop organization of fields to besummarized in a report. When a model is selected, the fields withavailable extraction rules are made available for use in the report. Auser selects some fields for organizing the report and others forproviding detail according to the report organization. For instance,region and salesperson may be organizing fields and sales data can besummarized (subtotaled and totaled) within this organization. Buildingreports using the PIVOT™ report generation interface is furtherexplained in Pivot Manual, Splunk Enterprise 6.1.3 (Aug. 4, 2014). Datavisualizations also can be generated in a variety of formats, byreference to the data model. Reports and data visualizations can besaved and associated with the data model for future use.

4. Query Processing

FIG. 3 presents a flowchart illustrating how a search head and indexersperform a search query in accordance with the disclosed embodiments. Atthe start of this process, a search head receives a search query from aclient at block 301. Next, at block 302, the search head analyzes thesearch query to determine what portions can be delegated to indexers andwhat portions need to be executed locally by the search head. At block303, the search head distributes the determined portions of the query tothe indexers. Note that commands that operate on single events can betrivially delegated to the indexers, while commands that involve eventsfrom multiple indexers are harder to delegate.

Then, at block 304, the indexers to which the query was distributedsearch their data stores for events that are responsive to the query. Todetermine which events are responsive to the query, the indexer searchesfor events that match the criteria specified in the query. Thesecriteria can include matching keywords or specific values for certainfields. In a query that uses a late-binding schema, the searchingoperations in block 304 may involve using the late-binding scheme toextract values for specified fields from events at the time the query isprocessed. Next, the indexers can either send the relevant events backto the search head, or use the events to calculate a partial result, andsend the partial result back to the search head.

Finally, at block 305, the search head combines the partial resultsand/or events received from the indexers to produce a final result forthe query. This final result can comprise different types of datadepending upon what the query is asking for. For example, the finalresults can include a listing of matching events returned by the query,or some type of visualization of data from the returned events. Inanother example, the final result can include one or more calculatedvalues derived from the matching events.

Moreover, the results generated by system 100 can be returned to aclient using different techniques. For example, one technique streamsresults back to a client in real-time as they are identified. Anothertechnique waits to report results to the client until a complete set ofresults is ready to return to the client. Yet another technique streamsinterim results back to the client in real-time until a complete set ofresults is ready, and then returns the complete set of results to theclient. In another technique, certain results are stored as “searchjobs,” and the client may subsequently retrieve the results byreferencing the search jobs.

The search head can also perform various operations to make the searchmore efficient. For example, before the search head starts executing aquery, the search head can determine a time range for the query and aset of common keywords that all matching events must include. Next, thesearch head can use these parameters to query the indexers to obtain asuperset of the eventual results. Then, during a filtering stage, thesearch head can perform field-extraction operations on the superset toproduce a reduced set of search results.

5. Field Extraction

FIG. 4 presents a block diagram illustrating how fields can be extractedduring query processing in accordance with the disclosed embodiments. Atthe start of this process, a search query 402 is received at a queryprocessor 404. Query processor 404 includes various mechanisms forprocessing a query, wherein these mechanisms can reside in a search head104 and/or an indexer 102. Note that the exemplary search query 402illustrated in FIG. 4 is expressed in Search Processing Language (SPL),which is used in conjunction with the SPLUNK® ENTERPRISE system. SPL isa pipelined search language in which a set of inputs is operated on by afirst command in a command line, and then a subsequent command followingthe pipe symbol “|” operates on the results produced by the firstcommand, and so on for additional commands. Search query 402 can also beexpressed in other query languages, such as the Structured QueryLanguage (“SQL”) or any suitable query language.

Upon receiving search query 402, query processor 404 sees that searchquery 402 includes two fields “IP” and “target.” Query processor 404also determines that the values for the “IP” and “target” fields havenot already been extracted from events in data store 414, andconsequently determines that query processor 404 needs to use extractionrules to extract values for the fields. Hence, query processor 404performs a lookup for the extraction rules in a rule base 406, whereinrule base 406 maps field names to corresponding extraction rules andobtains extraction rules 408-409, wherein extraction rule 408 specifieshow to extract a value for the “IP” field from an event, and extractionrule 409 specifies how to extract a value for the “target” field from anevent. As is illustrated in FIG. 4, extraction rules 408-409 cancomprise regular expressions that specify how to extract values for therelevant fields. Such regular-expression-based extraction rules are alsoreferred to as “regex rules.” In addition to specifying how to extractfield values, the extraction rules may also include instructions forderiving a field value by performing a function on a character string orvalue retrieved by the extraction rule. For example, a transformationrule may truncate a character string, or convert the character stringinto a different data format. In some cases, the query itself canspecify one or more extraction rules.

Next, query processor 404 sends extraction rules 408-409 to a fieldextractor 412, which applies extraction rules 408-409 to events 416-418in a data store 414. Note that data store 414 can include one or moredata stores, and extraction rules 408-409 can be applied to largenumbers of events in data store 414, and are not meant to be limited tothe three events 416-418 illustrated in FIG. 4. Moreover, the queryprocessor 404 can instruct field extractor 412 to apply the extractionrules to all the events in a data store 414, or to a subset of theevents that have been filtered based on some criteria.

Next, field extractor 412 applies extraction rule 408 for the firstcommand “Search IP=“10*” to events in data store 414 including events416-418. Extraction rule 408 is used to extract values for the IPaddress field from events in data store 414 by looking for a pattern ofone or more digits, followed by a period, followed again by one or moredigits, followed by another period, followed again by one or moredigits, followed by another period, and followed again by one or moredigits. Next, field extractor 412 returns field values 420 to queryprocessor 404, which uses the criterion IP=“10*” to look for IPaddresses that start with “10”. Note that events 416 and 417 match thiscriterion, but event 418 does not, so the result set for the firstcommand is events 416-417.

Query processor 404 then sends events 416-417 to the next command “statscount target.” To process this command, query processor 404 causes fieldextractor 412 to apply extraction rule 409 to events 416-417. Extractionrule 409 is used to extract values for the target field for events416-417 by skipping the first four commas in events 416-417, and thenextracting all of the following characters until a comma or period isreached. Next, field extractor 412 returns field values 421 to queryprocessor 404, which executes the command “stats count target” to countthe number of unique values contained in the target fields, which inthis example produces the value “2” that is returned as a final result422 for the query.

Note that query results can be returned to a client, a search head, orany other system component for further processing. In general, queryresults may include: a set of one or more events; a set of one or morevalues obtained from the events; a subset of the values; statisticscalculated based on the values; a report containing the values; or avisualization, such as a graph or chart, generated from the values.

6. Exemplary Search Screen

FIG. 6A illustrates an exemplary search screen 600 in accordance withthe disclosed embodiments. Search screen 600 includes a search bar 602that accepts user input in the form of a search string. It also includesa time range picker 612 that enables the user to specify a time rangefor the search. For “historical searches” the user can select a specifictime range, or alternatively a relative time range, such as “today,”“yesterday” or “last week.” For “real-time searches,” the user canselect the size of a preceding time window to search for real-timeevents. Search screen 600 also initially displays a “data summary”dialog as is illustrated in FIG. 6B that enables the user to selectdifferent sources for the event data, for example by selecting specifichosts and log files.

After the search is executed, the search screen 600 can display theresults through search results tabs 604, wherein search results tabs 604includes: an “events tab” that displays various information about eventsreturned by the search; a “statistics tab” that displays statisticsabout the search results; and a “visualization tab” that displaysvarious visualizations of the search results. The events tab illustratedin FIG. 6A displays a timeline graph 605 that graphically illustratesthe number of events that occurred in one-hour intervals over theselected time range. It also displays an events list 608 that enables auser to view the raw data in each of the returned events. Itadditionally displays a fields sidebar 606 that includes statisticsabout occurrences of specific fields in the returned events, including“selected fields” that are pre-selected by the user, and “interestingfields” that are automatically selected by the system based onpre-specified criteria.

7. Acceleration Techniques

The above-described system provides significant flexibility by enablinga user to analyze massive quantities of minimally processed performancedata “on the fly” at search time instead of storing pre-specifiedportions of the performance data in a database at ingestion time. Thisflexibility enables a user to see correlations in the performance dataand perform subsequent queries to examine interesting aspects of theperformance data that may not have been apparent at ingestion time.

However, performing extraction and analysis operations at search timecan involve a large amount of data and require a large number ofcomputational operations, which can cause considerable delays whileprocessing the queries. Fortunately, a number of acceleration techniqueshave been developed to speed up analysis operations performed at searchtime. These techniques include: (1) performing search operations inparallel by formulating a search as a map-reduce computation; (2) usinga keyword index; (3) using a high performance analytics store; and (4)accelerating the process of generating reports. These techniques aredescribed in more detail below.

7.1 Map-Reduce Technique

To facilitate faster query processing, a query can be structured as amap-reduce computation, wherein the “map” operations are delegated tothe indexers, while the corresponding “reduce” operations are performedlocally at the search head. For example, FIG. 5 illustrates how a searchquery 501 received from a client at search head 104 can split into twophases, including: (1) a “map phase” comprising subtasks 502 (e.g., dataretrieval or simple filtering) that may be performed in parallel and are“mapped” to indexers 102 for execution, and (2) a “reduce phase”comprising a merging operation 503 to be executed by the search headwhen the results are ultimately collected from the indexers.

During operation, upon receiving search query 501, search head 104modifies search query 501 by substituting “stats” with “prestats” toproduce search query 502, and then distributes search query 502 to oneor more distributed indexers, which are also referred to as “searchpeers.” Note that search queries may generally specify search criteriaor operations to be performed on events that meet the search criteria.Search queries may also specify field names, as well as search criteriafor the values in the fields or operations to be performed on the valuesin the fields. Moreover, the search head may distribute the full searchquery to the search peers as is illustrated in FIG. 3, or mayalternatively distribute a modified version (e.g., a more restrictedversion) of the search query to the search peers. In this example, theindexers are responsible for producing the results and sending them tothe search head. After the indexers return the results to the searchhead, the search head performs the merging operations 503 on theresults. Note that by executing the computation in this way, the systemeffectively distributes the computational operations while minimizingdata transfers.

7.2 Keyword Index

As described above with reference to the flow charts in FIG. 2 and FIG.3, event-processing system 100 can construct and maintain one or morekeyword indices to facilitate rapidly identifying events containingspecific keywords. This can greatly speed up the processing of queriesinvolving specific keywords. As mentioned above, to build a keywordindex, an indexer first identifies a set of keywords. Then, the indexerincludes the identified keywords in an index, which associates eachstored keyword with references to events containing that keyword, or tolocations within events where that keyword is located. When an indexersubsequently receives a keyword-based query, the indexer can access thekeyword index to quickly identify events containing the keyword.

7.3 High Performance Analytics Store

To speed up certain types of queries, some embodiments of system 100make use of a high performance analytics store, which is referred to asa “summarization table,” that contains entries for specific field-valuepairs. Each of these entries keeps track of instances of a specificvalue in a specific field in the event data and includes references toevents containing the specific value in the specific field. For example,an exemplary entry in a summarization table can keep track ofoccurrences of the value “94107” in a “ZIP code” field of a set ofevents, wherein the entry includes references to all of the events thatcontain the value “94107” in the ZIP code field. This enables the systemto quickly process queries that seek to determine how many events have aparticular value for a particular field, because the system can examinethe entry in the summarization table to count instances of the specificvalue in the field without having to go through the individual events ordo extractions at search time. Also, if the system needs to process allevents that have a specific field-value combination, the system can usethe references in the summarization table entry to directly access theevents to extract further information without having to search all ofthe events to find the specific field-value combination at search time.

In some embodiments, the system maintains a separate summarization tablefor each of the above-described time-specific buckets that stores eventsfor a specific time range, wherein a bucket-specific summarization tableincludes entries for specific field-value combinations that occur inevents in the specific bucket. Alternatively, the system can maintain aseparate summarization table for each indexer, wherein theindexer-specific summarization table only includes entries for theevents in a data store that is managed by the specific indexer.

The summarization table can be populated by running a “collection query”that scans a set of events to find instances of a specific field-valuecombination, or alternatively instances of all field-value combinationsfor a specific field. A collection query can be initiated by a user, orcan be scheduled to occur automatically at specific time intervals. Acollection query can also be automatically launched in response to aquery that asks for a specific field-value combination.

In some cases, the summarization tables may not cover all of the eventsthat are relevant to a query. In this case, the system can use thesummarization tables to obtain partial results for the events that arecovered by summarization tables, but may also have to search throughother events that are not covered by the summarization tables to produceadditional results. These additional results can then be combined withthe partial results to produce a final set of results for the query.This summarization table and associated techniques are described in moredetail in U.S. Pat. No. 8,682,925, issued on Mar. 25, 2014.

7.4 Accelerating Report Generation

In some embodiments, a data server system such as the SPLUNK® ENTERPRISEsystem can accelerate the process of periodically generating updatedreports based on query results. To accelerate this process, asummarization engine automatically examines the query to determinewhether generation of updated reports can be accelerated by creatingintermediate summaries. (This is possible if results from preceding timeperiods can be computed separately and combined to generate an updatedreport. In some cases, it is not possible to combine such incrementalresults, for example where a value in the report depends onrelationships between events from different time periods.) If reportscan be accelerated, the summarization engine periodically generates asummary covering data obtained during a latest non-overlapping timeperiod. For example, where the query seeks events meeting a specifiedcriteria, a summary for the time period includes only events within thetime period that meet the specified criteria. Similarly, if the queryseeks statistics calculated from the events, such as the number ofevents that match the specified criteria, then the summary for the timeperiod includes the number of events in the period that match thespecified criteria.

In parallel with the creation of the summaries, the summarization engineschedules the periodic updating of the report associated with the query.During each scheduled report update, the query engine determines whetherintermediate summaries have been generated covering portions of the timeperiod covered by the report update. If so, then the report is generatedbased on the information contained in the summaries. Also, if additionalevent data has been received and has not yet been summarized, and isrequired to generate the complete report, the query can be run on thisadditional event data. Then, the results returned by this query on theadditional event data, along with the partial results obtained from theintermediate summaries, can be combined to generate the updated report.This process is repeated each time the report is updated. Alternatively,if the system stores events in buckets covering specific time ranges,then the summaries can be generated on a bucket-by-bucket basis. Notethat producing intermediate summaries can save the work involved inre-running the query for previous time periods, so only the newer eventdata needs to be processed while generating an updated report. Thesereport acceleration techniques are described in more detail in U.S. Pat.No. 8,589,403, ISSUED ON Nov. 19, 2013, AND U.S. Pat. No. 8,412,696,ISSUED ON Apr. 2, 2011.

8. Security Features

The SPLUNK® ENTERPRISE platform provides various schemas, dashboards andvisualizations that make it easy for developers to create applicationsto provide additional capabilities. One such application is the SPLUNK®APP FOR ENTERPRISE SECURITY, which performs monitoring and alertingoperations and includes analytics to facilitate identifying both knownand unknown security threats based on large volumes of data stored bythe SPLUNK® ENTERPRISE system. This differs significantly fromconventional Security Information and Event Management (SIEM) systemsthat lack the infrastructure to effectively store and analyze largevolumes of security-related event data. Traditional SIEM systemstypically use fixed schemas to extract data from pre-definedsecurity-related fields at data ingestion time, wherein the extracteddata is typically stored in a relational database. This data extractionprocess (and associated reduction in data size) that occurs at dataingestion time inevitably hampers future incident investigations, whenall of the original data may be needed to determine the root cause of asecurity issue, or to detect the tiny fingerprints of an impendingsecurity threat.

In contrast, the SPLUNK® APP FOR ENTERPRISE SECURITY system stores largevolumes of minimally processed security-related data at ingestion timefor later retrieval and analysis at search time when a live securitythreat is being investigated. To facilitate this data retrieval process,the SPLUNK® APP FOR ENTERPRISE SECURITY provides pre-specified schemasfor extracting relevant values from the different types ofsecurity-related event data, and also enables a user to define suchschemas.

The SPLUNK® APP FOR ENTERPRISE SECURITY can process many types ofsecurity-related information. In general, this security-relatedinformation can include any information that can be used to identifysecurity threats. For example, the security-related information caninclude network-related information, such as IP addresses, domain names,asset identifiers, network traffic volume, uniform resource locatorstrings, and source addresses. (The process of detecting securitythreats for network-related information is further described in U.S.patent application Ser. Nos. 13/956,252, and 13/956,262.)Security-related information can also include endpoint information, suchas malware infection data and system configuration information, as wellas access control information, such as login/logout information andaccess failure notifications. The security-related information canoriginate from various sources within a data center, such as hosts,virtual machines, storage devices and sensors. The security-relatedinformation can also originate from various sources in a network, suchas routers, switches, email servers, proxy servers, gateways, firewallsand intrusion-detection systems.

During operation, the SPLUNK® APP FOR ENTERPRISE SECURITY facilitatesdetecting so-called “notable events” that are likely to indicate asecurity threat. These notable events can be detected in a number ofways: (1) an analyst can notice a correlation in the data and canmanually identify a corresponding group of one or more events as“notable;” or (2) an analyst can define a “correlation search”specifying criteria for a notable event, and every time one or moreevents satisfy the criteria, the application can indicate that the oneor more events are notable. An analyst can alternatively select apre-defined correlation search provided by the application. Note thatcorrelation searches can be run continuously or at regular intervals(e.g., every hour) to search for notable events. Upon detection, notableevents can be stored in a dedicated “notable events index,” which can besubsequently accessed to generate various visualizations containingsecurity-related information. Also, alerts can be generated to notifysystem operators when important notable events are discovered.

The SPLUNK® APP FOR ENTERPRISE SECURITY provides various visualizationsto aid in discovering security threats, such as a “key indicators view”that enables a user to view security metrics of interest, such as countsof different types of notable events. For example, FIG. 7A illustratesan exemplary key indicators view 700 that comprises a dashboard, whichcan display a value 701, for various security-related metrics, such asmalware infections 702. It can also display a change in a metric value703, which indicates that the number of malware infections increased by63 during the preceding interval. Key indicators view 700 additionallydisplays a histogram panel 704 that displays a histogram of notableevents organized by urgency values, and a histogram of notable eventsorganized by time intervals. This key indicators view is described infurther detail in pending U.S. patent application Ser. No. 13/956,338filed Jul. 31, 2013.

These visualizations can also include an “incident review dashboard”that enables a user to view and act on “notable events.” These notableevents can include: (1) a single event of high importance, such as anyactivity from a known web attacker; or (2) multiple events thatcollectively warrant review, such as a large number of authenticationfailures on a host followed by a successful authentication. For example,FIG. 7B illustrates an exemplary incident review dashboard 710 thatincludes a set of incident attribute fields 711 that, for example,enables a user to specify a time range field 712 for the displayedevents. It also includes a timeline 713 that graphically illustrates thenumber of incidents that occurred in one-hour time intervals over theselected time range. It additionally displays an events list 714 thatenables a user to view a list of all of the notable events that matchthe criteria in the incident attributes fields 711. To facilitateidentifying patterns among the notable events, each notable event can beassociated with an urgency value (e.g., low, medium, high, critical),which is indicated in the incident review dashboard. The urgency valuefor a detected event can be determined based on the severity of theevent and the priority of the system component associated with theevent. The incident review dashboard is described further in“http://docs.splunk.com/Documentation/PCI/2.1.1/User/IncidentReviewdashboard.”

9. Data Center Monitoring

As mentioned above, the SPLUNK® ENTERPRISE platform provides variousfeatures that make it easy for developers to create variousapplications. One such application is the SPLUNK® APP FOR VMWARE®, whichperforms monitoring operations and includes analytics to facilitatediagnosing the root cause of performance problems in a data center basedon large volumes of data stored by the SPLUNK® ENTERPRISE system.

This differs from conventional data-center-monitoring systems that lackthe infrastructure to effectively store and analyze large volumes ofperformance information and log data obtained from the data center. Inconventional data-center-monitoring systems, this performance data istypically pre-processed prior to being stored, for example by extractingpre-specified data items from the performance data and storing them in adatabase to facilitate subsequent retrieval and analysis at search time.However, the rest of the performance data is not saved and isessentially discarded during pre-processing. In contrast, the SPLUNK®APP FOR VMWARE® stores large volumes of minimally processed performanceinformation and log data at ingestion time for later retrieval andanalysis at search time when a live performance issue is beinginvestigated.

The SPLUNK® APP FOR VMWARE® can process many types ofperformance-related information. In general, this performance-relatedinformation can include any type of performance-related data and logdata produced by virtual machines and host computer systems in a datacenter. In addition to data obtained from various log files, thisperformance-related information can include values for performancemetrics obtained through an application programming interface (API)provided as part of the vSphere Hypervisor™ system distributed byVMware, Inc. of Palo Alto, Calif. For example, these performance metricscan include: (1) CPU-related performance metrics; (2) disk-relatedperformance metrics; (3) memory-related performance metrics; (4)network-related performance metrics; (5) energy-usage statistics; (6)data-traffic-related performance metrics; (7) overall systemavailability performance metrics; (8) cluster-related performancemetrics; and (9) virtual machine performance statistics. For moredetails about such performance metrics, please see U.S. patent Ser. No.14/167,316 filed 29 Jan. 2014, which is hereby incorporated herein byreference. Also, see “vSphere Monitoring and Performance,” Update 1,vSphere 5.5, EN-001357-00,http://pubs.vmware.com/vsphere-55/topic/com.vmware.ICbase/PDF/vsphere-esxi-vcenter-server-551-monitoring-performance-guide.pdf.

To facilitate retrieving information of interest from performance dataand log files, the SPLUNK® APP FOR VMWARE® provides pre-specifiedschemas for extracting relevant values from different types ofperformance-related event data, and also enables a user to define suchschemas.

The SPLUNK® APP FOR VMWARE® additionally provides various visualizationsto facilitate detecting and diagnosing the root cause of performanceproblems. For example, one such visualization is a “proactive monitoringtree” that enables a user to easily view and understand relationshipsamong various factors that affect the performance of a hierarchicallystructured computing system. This proactive monitoring tree enables auser to easily navigate the hierarchy by selectively expanding nodesrepresenting various entities (e.g., virtual centers or computingclusters) to view performance information for lower-level nodesassociated with lower-level entities (e.g., virtual machines or hostsystems). Exemplary node-expansion operations are illustrated in FIG.7C, wherein nodes 733 and 734 are selectively expanded. Note that nodes731-739 can be displayed using different patterns or colors to representdifferent performance states, such as a critical state, a warning state,a normal state or an unknown/offline state. The ease of navigationprovided by selective expansion in combination with the associatedperformance-state information enables a user to quickly diagnose theroot cause of a performance problem. The proactive monitoring tree isdescribed in further detail in U.S. patent application Ser. No.14/235,490 filed on 15 Apr. 2014, which is hereby incorporated herein byreference for all possible purposes.

The SPLUNK® APP FOR VMWARE® also provides a user interface that enablesa user to select a specific time range and then view heterogeneous data,comprising events, log data and associated performance metrics, for theselected time range. For example, the screen illustrated in FIG. 7Ddisplays a listing of recent “tasks and events” and a listing of recent“log entries” for a selected time range above a performance-metric graphfor “average CPU core utilization” for the selected time range. Notethat a user is able to operate pull-down menus 742 to selectivelydisplay different performance metric graphs for the selected time range.This enables the user to correlate trends in the performance-metricgraph with corresponding event and log data to quickly determine theroot cause of a performance problem. This user interface is described inmore detail in U.S. patent application Ser. No. 14/167,316 filed on 29Jan. 2014, which is hereby incorporated herein by reference for allpossible purposes.

Technology Disclosed

FIG. 8 illustrates a portion of a wizard that guides a user through astructured sequence of steps to produce extraction rules. The number ofsteps involved depends on the context from which extraction ruleformulation begins. The number of steps also depends on designerpreferences, so a system borrowing from the technology disclosed couldseparate features of a single step into multiple steps or could combinefeatures of two steps into a single step. A computer-implemented methodis, for convenience of understanding, described with reference to one ormore modules running on hardware in a hardware environment as describedabove. However, the particular hardware mentioned is not necessary tothis computer-implemented method. One GUI implementation of thecomputer-implemented method is illustrated, but the selection andarrangement of features for a particular GUI page will look different inalternative implementations. The appearance of the GUIs illustrated isnot necessary to this computer-implemented method.

Five steps are illustrated in FIG. 8. Selecting a so-called sourcetype802 is the first step. Generally, this involves identifying a datasource or subset of a data source for which one or more extraction ruleswill be formulated. Examples of sourcetypes may be application servers,data servers, routers, load balancers or other machines of similartypes. Sourcetypes can be further refined by type, region, usage oranother sub type. When different machine brands or equipment generationsproduce distinct formats of machine data output, it can be convenient tosub type the sourcetype to make it easier to formulate extraction rules.Within a sourcetype, field names can be reused across sub types evenwhen different extraction rules are required to extract field valuesfrom distinct formats of machine data.

FIG. 8 also shows a control for selecting a sourcetype 822. Theillustrated control is a pull down menu. A variety of other controlscould be used such as an auto-completion field or a scrollable list.

The progress line 802-808 indicates progress through the structuredsequence from selecting a sourcetype 802, to selecting at least oneexample event 804, selecting fields from the example event 805,validating the selected fields 806, and concluding with saving 808 theextraction rule produced from this sequence of steps. A step selector809 can move a user forwards or backwards through the structuredsequence. When a user chooses to go back, the system can rememberchoices made and auto-complete them when the later step is revisited, ifthe prior choices remain valid.

The number of steps involved can be reduced by borrowing context fromthe system state that the user has reached when the extraction rulegenerator is invoked. The extraction rule generator is a module runningon suitable hardware. When the user is already browsing data from aparticular sourcetype using some other tool, a wizard can recognize thata sourcetype has been selected and either begin with the second step ofselecting an example or can shorten the progress line from five steps tofour.

Similarly, if browsing data has led the user to focus on a particularevent, the wizard can recognize that a sourcetype and example event havebeen selected. Then, the process can begin with the third step or besimplified to just three steps. Recognizing context from other analysistools allow a rule extraction module to begin at an appropriate step andminimize reentry of user selections. Progress through the structuredsequence is illustrated in the following figures.

Not shown in any of these figures is a GUI implementation of selectingan event from a list in step 804, as this is straightforward.

FIG. 9 illustrates a portion of a GUI that features one example eventthat has been marked up to indicate fields to extract and previewresults of applying an extraction rule. This GUI implements the selectfields 805 step in the structured sequence.

In area 910, an example event for markup has been selected. This exampleappears to be a log entry related to an HTTP GET command. In thiscontext, so-called markup can be as simple as selecting one or moretokens to be extracted together. Highlighting by drag and release,touching, gesturing, clicking, double-click or spoken selection can beapplied to one or more tokens. For this example event, three tokensalready have been selected and given field names. The token “GET” 914has been selected and given the field name “method” 932. Thehighlighting of the selected token can be color-coded or matched byanother visual cue between the token 914, the named tab 932, instancesof extracted method tokens in displayed events 951, 961, and theextracted token column 967 for the method field. Not all of these GUIelements need to be used in a particular implementation and any subsetof them can be visual cue-coordinated. The token “200” 916 has beenselected and named “status” 933. Similarly, “376” 918 has is the tokenfor field “bytes” as in the size of the GET command or command responsereferenced by the log.

Control 920 allows a user to view the field extraction rule directly.User editing of the field extraction rule can be supported by the GUI,allowing the user to write an extraction rule in place of theautomatically generated rule or to modify the automatically generatedrule. In some implementations, a separate manual mode is supported forextraction rule development. The sampling and analysis tools support amanual development mode and can be combined with rule editing tools.

Events tab 931, when selected, can provide further controls and listingof events as shown in the figure. Among adjoining tabs 930, thefield-associated tabs 932, 933, 934 each provide access to analysis ofvalues extracted for a field, as illustrated in FIG. 10. In thisillustration, the fields are named method 932, status 933, and bytes934. The events tab 931 is directed to events, instead of fields. Twosample events 951, 961 appear in the figure. In each of the sampleevents, the extracted values for the three fields are highlighted. Forevent 951, the values “GET”, “200” and “420” are highlighted. Thesevalues can be color coded to match tabs 932, 933, 934 and to furthermatch values in the marked up example event 914, 916, 918. When a cursoror other selection tool focuses on event 951, an add example control 959appears to add the example event as a secondary example. One or moreadditional example events can be added, as shown in FIG. 13A. The addexample control 959 could also be implemented as a tool tip or a columnof checkboxes. In this illustration, extracted values for the listedevents are also displayed in columns for ease of scanning. This makesthe extracted values visible both in context and in a column list.Various implementations can include just the display in context, in thebody of the events, or just the columns 967, 968. The appearance can beuser controllable and defaults can be set by sourcetype/sub type.Different appearances may be useful depending on the size andreadability of an event record. In addition to event listing, the eventstab can include controls for sampling and display of events.

The field-associated tabs 932, 933, 934 are further discussed in thecontext of FIG. 10.

Sampling controls 942, 946 determine the events analyzed and availablefor display. The time range sampling control 942 gives a user controlover which subset of a larger event universe will be used for extractionrule development. One set of choices is illustrated in FIG. 12A using apull-down list. Slider or direct entry controls also could be used tochoose a time range. The choices 1215, 1225 specify a time rangeindirectly by number of events 1215 or directly by time 1225. In thisexample, the first or last (most recent) 1,000 or 10,000 events might beselected. More directly, the last 5 minutes, 24 hours or 7 days can beselected. A slider control could be calibrated to time and date, numberof events or both. As in a video editing tool, the scale of a slidercontrol could be adjustable to allow coarse selection in an availablerange and fine selection once focused on part of the available data.Direct entry controls could identify starting and stopping times or justone time and a number events before, after or centered on the specifiedtime.

In some implementations, text is supplied that reminds the user of thecurrent filters and/or data subset that are being used. In FIG. 8, textappears below tabs 930. The text illustrated confirms the time rangeselection applied. Similar text could be supplied to describeapplication of other controls.

For events that have a different primary organization than time, such asgeo-located events, other controls for selecting a primary samplingrange could be substituted for or added to the illustrated time rangesampling controls. A geo-located control could use a location selectionand circle or rectangle centered on a selected location. Or, ageo-located control could select one or more predefined regions, such asa political subdivision, an SMSA, a zip code or similar territory. Ageo-located control could be combined with a time range control ofsampling.

Sampling strategy control 945 further determines how the events analyzedare selected. Three options of all events 1235, diverse events 1245 andrare events 1255 are illustrated in a pull down control in FIG. 12B. Inone implementation, these controls refer to whether a sample isclustered before sample events to display are selected. There are manyways to cluster a sample. Some ways to form clusters are described inthe incorporated by reference application Ser. Nos. 14/168,888 and13/747,153, parts of which are reproduced below. In general, clusteringor cluster analysis approaches can be adapted from many sources. Thereare on the order of 100 published cluster algorithms, many of which areadaptable to event sampling. Cluster Analysis. Wikipedia. [retrieved2015-01-11]. Retrieved from the Internet <URL:http://en.wikipedia.org/wiki/Cluster_analysis>. The sampling strategycontrol 945 determines whether clustering is applied 1245, 1255 or not1235. Two sampling strategies from clusters are offered in theillustrated. Selection of diverse events 1245 favors a sample of eventsfrom large clusters. Selection from large clusters covers a large anddiverse proportion of the sampled events. To accomplish diversity, onesampling strategy is to sample from larger clusters and pick apredetermined number of samples, e.g., one, two, three, five, ten or inthat range of samples from each of the larger clusters. The number ofsamples selected can automatically adjust to the number of clustersdefined. The number of clusters defined can be responsive to a userselectable similarity threshold for forming a cluster or a userselectable control over the number of clusters formed (as used instatistical factor analysis.)

A similarly threshold control can determine a number of similarityparameters, including how special tokens, such as IP addresses orURLs/URNs/URIs, are handled. For instance, the similarity threshold candetermine how many of the four octal groups in an IP address need tomatch for two IP address tokens to be considered matching.

When there are a small number of clusters, such as 20-100 clusters, theclusters can be rank ordered in size and the largest clusters used forsampling. When the number of clusters is larger, exceeding apredetermined number of samples to display to a user, or when adifferent approach is desired, selection among the larger clusters mayfollow a different pattern. For instance, the top quartile clusters ofor the clusters that hold at least one half percent of the eventpopulation could be identified. From the identified clusters, a furtherrandom or periodic selection could be applied. The result of selectingthe diverse events control 1245 is that the system picks a handful ofsample events from each of the identified larger clusters. Any exampleevents being used for highlighting can be considered part of the sample.The data transmitted for display to the user reveals diverse patterns ofevent data that are from larger, more common clusters of events.

The rare events control 1255 also involves clustering, but favorssamples from small clusters. Either smallest clusters or clusters withinthe lower quartile or other cluster size band can be identified. Aminimum cluster size can be applied to avoid devoting too much userattention to unique or nearly unique events in a large event population.The result of selecting the rare events control 1255 is that the systempicks a handful of sample events from each of the identified smallerclusters. The data transmitted for display to the user reveals rareinstances of event data, which can be useful in refining an extractionrule or in deciding how many extraction rules are needed to extract datafrom a sourcetype that has multiple distinct formats and that requiresmultiple extraction rules to handle the distinct formats. A combinationof controls, including the time range and sampling strategy controls,can be applied before or after an example event is selected and markedup for field extraction.

After selection of fields within the example event, a match or notcontrol 946 can be applied. Match or not refers to whether the currentversion of the extraction rule succeeds in extracting all specifiedfields or not from a particular event. Either because the sample eventshave distinct formats that are not all handled by a single extractionrule or because the rule under development needs refinement, there canbe some or many sample events that the current extraction rule does notmatch or fails when applied. Three values of match or not areillustrated as alternative buttons, like radio buttons but without thedots. The match or not selections illustrated 946 are all events,matches and non-matches. These controls could be presented as a pulldown menu or other type of control. Selection of all events, clears thisfilter. Selection of the matches option, filters sample events to justthose events that the current extraction rule succeeds in matching or inextracting values from. Selection of the non-matches option filterssample events to ones that the current extraction rule fails to match orcannot extract values from. The match choice of control 946 can be usedto identify negative examples. The non-match choice of control 946 canbe used to identify additional example events and provide additionalpositive examples, as illustrated in FIGS. 13A-13B. Controls transmittedto a user for display can

Filter 940 can accept keyword or key-value filters. A key-value filterspecifies both a field name and a field value. The field name can eitherbe a system extracted field name or a field name specified with anextraction rule. A value can include a wild card character. Or the valuecan simply be matches or exists. When a filter 940 is specified, onlyevents that match the filter are transmitted for displayed. Thisfiltering behavior also can be incorporated in extraction rules, asdescribed for FIG. 16, below.

The controls in FIG. 9, as a group, support selection of fields,automatic generation of field extraction rules and direct entry orediting of rules.

FIG. 10 illustrates a portion of a GUI that details extraction resultsfor a particular field named “bytes.” The preview panel in FIG. 10includes many of the same controls as FIG. 9. However, the match or notcontrols 946 are not included because this tab analyzes matches. Thefigure shows each value extracted on a separate row, with four columns.The presentation can be arranged in other ways, such as columns or a piechart. Values extracted 1002 of the illustrated table are shown in theleft-hand column. Some of the values extracted from the sample eventsare “327”, “205”, and “643”. Another column 1005 gives a count for thenumber of times each value in column 1002 was extracted. The text justbelow the events tab 931, indicates that the sample includes 1000events. Thus, a count of seven extractions of the “327” bytescorresponds to 0.7% of the rows in the sample. This percentage appearsin column 1008. This fraction can be graphically illustrated in anadditional column 1009 as a bar graph or other visual cue. The rows canfurther implement row controls, for instance by a hyperlink from a valuein column 1002, that populate the filter control 940 with the selectedvalue. As shown in FIG. 11, selection of a row control reverts the GUIto the events tab 931 with a key-value filter set in the filter control940. The user can scroll through rows of this field-value analysis taband find values are out of place. For instance, extraction of the textstring for the number of bytes would be an apparent error. A user couldselect the row control for the character string appearing in the valuescolumn 1002 and use tools to select or validate fields to refine theextraction rule so that character strings would not be selected for thenumber of bytes field. Extracted values that look wrong, such ascharacters in a numeric column, and values that are unique, such as in astatus column, are more easily spotted by a user in this analysis GUIthan in an events list GUI. This can also provide an experience of‘coverage’ or ‘confidence rating’ within a sourcetype. ‘Coverage’ is thepercentage of tokens within events of a sourcetype that have extractedvalues. For example, if all words of all events within a sourcetype haveassociated extractions, the sourcetype would be considered to have 100%coverage. ‘Confidence rating’ is a form of analysis of existingextractions that make up the coverage, providing insight into theestimated success of the extractions, rating individual extractionsbased on the typical, token type, format, or language. For example, ifBYTES is comprised of 99%+ integer values, and a word like “penguin’ ora special character such as ‘&’ is encountered, a flag can be raised andthe confidence rating of the sourcetype's ‘coverage’ can be impacted.

FIG. 11 illustrates a portion of a GUI with a key-value filter appliedto events and sample events that satisfy the filter. The user couldreach this GUI either by selecting a row in the status tab for extractedstatus “503” or by entering the key-value pair “status=503” in thefilter control window 940. Following entry of the key-value pair shown,the events transmitted for display 1151, 1161, 1171 all have the value“503” in the status field. This value is highlighted in each of the rowsand also displayed in the status column 968. From the other extractedvalue columns for method 967 and bytes 969, one can see that the statusis not tied to either the method or the number of bytes, as the valuesin those extracted columns vary among events with status “503”. Use ofthe filter window 940 does not change the available tabs 930 or thecontrols for sampling and display 942, 943, 946.

FIGS. 12A-12B illustrate pull down menu implementations that selectamong sampling strategies to select sample events. In FIG. 12A, choicesin the first pull down menu 942 allow selection of events occurring inthe beginning of the data source 1215, and for selection of eventsoccurring at the end of the data source 1225. The first pull down menu942 has a label that equals the word “Sample:” with the selection madefrom the first pull down menu appended. In this example, the label ofthe first pull down menu 942 is “Sample: First 1,000 events”. This labelchanges to match whatever selection is made from the first pull downmenu 942. The first pull down menu 942 can contain any number of timefilters, and their presentation for selection is not limited to themethod presented in FIG. 12A.

In FIG. 12B, the second pull down menu 945 allows for selection of allevents 1235, diverse events 1245, or rare events 1255. “All events” 1235would remove this as a filter for the extraction. “Diverse events” 1245and “Rare events” 1255 are examples of cluster types defined above. Inthis example, as “All events” 1235, “Diverse events” 1245, or “Rareevents” 1255 are selected from the second pull down menu 945, the labelfor object 945 is changed to match that of the selection.

FIGS. 13A and 13B illustrate portions of a GUI that presents secondaryexamples of events to mark up to generate a more-inclusive extractionrule. In FIG. 13A, only event 1315 and not events 1325, 1335, 1345,1355, have had fields identified for extraction by the initialextraction rule, which was based on just one example event. This isindicated by lack of marking of fields in events 1325, 1335, 1345, 1355.Selection as secondary example events is indicated by the indentation,the circle-x control to the left of events 1325, 1335, 1345, 1355, andthe position below primary example 1315. These secondary example eventswere selected, for example, using control 959 in FIG. 9. In this figure,the primary example 1315 already has been marked up and the secondaryexamples are available to mark up.

The initial markup of primary example 1315 selected fields named “IP”1312, “thing” 1313 and “thing2” 1314. The “thing” field 1313 in event1315 contains the string “STP-W-PORTSTATUS”. Using just this example,the first extraction rule was so tailored to the string“STP-W-PORTSTATUS” that none of the secondary events 1325-1355 matchedthe extraction rule. Closer analysis of the secondary events revealswhy.

The secondary example events are not quite ALL CAPS. Some of thesecondary events, e.g. 1325, have the string “LINK-I-Up” which isMIXED-Case. The user could select “LINK-I-Up” in event 1325 as apositive example of a value to be extracted. The user also could select“LINK-W-Down” in event 1355 as a positive example. With one or both ofthese additional positive examples, the system generates an updated thefield extraction rule. The updated field extraction rule cannot requirecapitalized letters in the “thing” field; it might not require capitalletters or not require capital letters after one or two hyphens “-”. Theupdated field extraction rule would then match events 1325, 1335, 1345,and 1355, in addition to event 1315, which matched the initial fieldextraction rule.

Marking up a secondary example can further include linking marked uptext to an previously created field, as a second example of what toextract for that field. In FIG. 13B, a pop-up window 1327 is illustratedfor selecting a field name among the fields that appear in the primaryexample. The user selects the field name for the marked up text in thesecondary example event. In this figure, an IP address 1324 has beenselected from event 1325. The field name pop up 1327 displays the namesof three previously created fields that appear in event 1315. The markedup IP address 1324 in event 1325 is assigned the field name “IP” 1329.

FIG. 14 illustrates a portion of a GUI that previews results of applyingan extraction rule formulated using multiple example events and positiveexamples of values to select. This figure shows that introducing thesecond example event 1325 causes the system to update the wholeextraction rule, not just the part of the extraction rule that capturesthe highlighted secondary positive example 1324. A valid secondaryexample event 1325 contains the same fields to extract as the primaryexample event 1315. This secondary example event is valid because thefinal string in the primary event, “STP status Forwarding” has not beenhighlighted for extraction. The system automatically finds all thefields highlighted in the primary example event 1315 somewhere withinthe secondary example event 1325 and updates the extraction ruleaccordingly. Because the secondary example event includes the mixed casetext “LINK-I-Up”, a new extraction rule is generated that coincidentallymatches events 1445, 1447, in addition to events 1441, 1444 that havethe same “thing” field value as event 1325. The checkmarks in column1440 reinforce the highlighting in the events, indicating that all theevents 1441-1447 in this display match the extraction rule.

FIGS. 15A and 15B illustrate how one selected field can anchor selectionof an additional field. This sequence of figures illustrate howso-called anchoring of a difficult to extract field 1517 to a nearbyeasily extracted field 1516 can aid in the generation of an effectiveextraction rule 1545, 1546. Not shown is failure of the system togenerate an extraction rule with these primary and secondary exampleevents, when the only field highlighted is the token string 1517 “STPstatus forwarding”—there is no separate figure illustrating a failuremessage. An automatic field extraction process, in some instances, mightinitially fail to formulate a rule that would extract the text in field1517, due to secondary example 1525. This might be because the primaryexample event has one more field than the secondary example event. Theextraction rule for two of the fields in common between the primary andsecondary example events is illustrated 1545. In FIG. 15B, field 1517has been highlighted and a new extraction rule generated. The newextraction rule succeeds because it selects zero or more charactersafter the anchoring field 1516. An astute programmer in the regularexpression language might recognize that an optional extraction field isavailable they could be used in the extraction rule as an alternative tozero or more characters. Either way, specification of another field toextract is necessary before a trailing field of zero or more characterscan be extracted.

FIG. 16 illustrates requiring that a so-called required value be foundin every event selected. This can be particularly useful when the eventsappear in multiple distinct formats that require multiple extractionrules to correlate data among the formats. This figure shows another wayto deal with the diversity in number of fields for events with the token“STP-W-PORTSTATUS” 1315, as opposed to the link up and link down events1325-1355. The sample event type 1315, as illustrated in FIGS. 13-15 hasone more field 1517 then the other event types. Going back to theexample above, use of a required value can be used to create multipleextraction rules covering diverse format. In the example above, oneextraction rule optionally extracted zero or more characters followingthe third field. Using one or more required field values, separateextraction rules can be specified for events with different numbers offields, events in two distinct formats. FIG. 16 illustrates a pop-upcontrol used to require 1636 presence of the token “STP-W-PORTSTATUS”1315 in order for the extraction rule to succeed. In one implementation,a token can either be extracted or required to be present, but not both.In other implementations, the same token could be required andextracted.

FIG. 17 illustrates three extensions of field extraction rules:concatenate, trim and extract-from-extraction. In the context of alate-binding schema, complex definition of fields is problematic,because the fields are repeatedly extracted at query time, rather thanbeing extracted and transformed once, for loading into structured fields(ETL—extract, transform and load). Nonetheless, some extensions areproposed. The examples in FIG. 17 do not correspond to the examplesdescribed below. Instead, they are intended to indicate an exampleinterface that could be used with the data examples that follow.

Field extraction rules are extended by allowing concatenation of twoextractions 1714, 1716 for one field with an optional literal 1726separating the extractions. During selection of values to extract, acontrol is selected that concatenates non-adjoining two token regions1724, 1725. This control gives allows a user the option of specifyingliteral text 1726 to insert between two extracted substrings. Both ofthe concatenated extractions are part of the same extraction rule.

For example, a user can select two or more objects where an object iseither an existing field, or a selection of text within an existingfield (a selection of text within an existing field is essentially asecondary extraction) with the intention of creating a new field. Or theuser can select one object with the addition of manual text input. Themethod of creating the concatenated field is through the use of Splunk's“Eval” command, like so:

Search:

month_field=*day_field=*year_field=*|evalfull_date=month_field+“/”+day_field+“/”+year_field

Applied to one event from the data store, when the extracted value ofmonth_field is “11”, of day_field is “30”, and of year_field is “1982”,the concatenated full_date field contains the value “11/30/1982”.

Extraction rules for fields 1734 also are extended by allowing trimmingof extracted values. In some instances, an extraction rule will returnuseful text with a repeated or unhelpful prefix or suffix. For instance,a string with parameters might be extracted, but only one of theparameters 1732 is of interest. Trimming 1736 can be used to deletecharacters before and after the parameter of interest.

Two methods of implementing trim are described, which could bealternatively applied, depending on which succeeds. In these methods,trim is like a secondary extraction.

In the first method, the desired secondary extraction can be indicatedby the user through highlighting a desired value. If the user selects“mpideon” from “mpideon-admin”, the method can generate an extractionrule that effectively trims “-admin” or more generally trims“-<user_type>”.

In the second method, the desired secondary extraction can be indicatedthrough an explicit trim definition. User would select the originalfield and input either a number of characters, a specific characterpattern, or a combination of the two, as well as the position (beginningor end). The system could automatically generate a RegEx as a newextraction rule. The new extraction rule could contain the explicitcharacter pattern or the number of characters and position as part ofthe RegEx.

It is possible that both method 1 and method 2 for a given set of datawould generate identical extraction rules. However, in cases wheremethod 1 fails, a user or system could apply method 2.

Alternatively, a secondary extraction rule 1756 can be applied to anextracted value could to find a parameter 1752 within a string of aprimary field 1754. A first extraction rule extracts a string thatincludes, for instance, parameters, regardless of whether or not theyinclude a particular substring of interest. One or more secondaryextraction rules could be applied to the extracted string to find theparameter string of interest and generate a secondary field 1765. Onesecondary extraction rule could extract the parameter of interest.Another secondary extraction rule could extract another feature.

To illustrate, in the context of event: “Passwd entry uid=mpideon-admincn=users dc=osx dc=splat dc=com” The field name associated with thevalue “mpideon-admin” is “uid”.

Extracting the value “admin” as a field name “user_type” from the eventmay be too difficult for an automatic extraction rule generator.However, suppose the user is able to extract the value “mpideon-admin”using any of:

1. a regular expression (perhaps because it was easier for the algorithmto determine)

2. an auto-key=value extraction rule (always extract key=valueinformation)

3. a delimiter/header definition (delimiter is “space”, columns are“col1,col2,uid,col4,col5,col6,col7” where “uid=mpideon-admin” is uid),

Then, automatic extraction rule generation can more easily extractuser_type (“admin” value) because the pattern matching domain is limitedtoe field values such as mpideon-admin or, more generally, xxx-yyy,rather than the entire event text.

The implementation could look something like: Extraction rule for UID:“uid\=(?<uid>\S+)\s+” FROM_raw

Note: “FROM_raw” is implicit—this is typically not included in theextraction rule, because if there is no “FROM xxx” the system assumesthe domain of the extraction is the raw event.

Secondary extraction rule for user_type: “[^\-]+(?<user_type>.*)” FROMuid

The same secondary extraction rule could be used regardless of how theprimary extraction of “uid” was performed, such as regex, automaticextraction of key=value pairs, or delimiter based.

FIG. 18A illustrates a portion of a validation GUI. Using this GUI, auser can identify negative examples of matched data values; that is,values that should not be matched by the extraction rule. This GUIimplements the validate fields 806 step in the structured sequence.

The structured sequence collects positive examples in the select fieldsstep 805, before accepting negative examples in the validate fields step806. The sample events (e.g., 1442, 1443) can be selected using any ofthe filters, analysis tools or sampling strategies described throughoutthis disclosure.

The GUI 1800 allows for validation of value extractions and removal ofvalues that are incorrectly highlighted as positive examples in theevents tab 931. The GUI provides the reclassification from positive tonegative any values that have been highlighted 1515, 1516, 1517 byselecting an “x” control (e.g., 1835). This control generates data toreclassify a value, such as “STP-W-PORTSTATUS” 1515, from a positiveexample to a negative example. This registers the value as a negativeexample for extraction rule creation and reruns the extraction rule,resulting in removal of the highlighting of previously positive valueselsewhere among sample events, such as 1516 and 1517. Similarly, thevalue “e4” 1516 can be changed from a positive to a negative example byselecting control 1836. Providing a negative example causes the systemto update and reapply the extraction rule.

FIG. 18B illustrates formatting an example event to indicate that atoken in the example event has been registered as a negative example. Inthe example event window 1835, the value 1515 is marked with astrike-through font. Other visual cues such as a red typeface could beused. In the list of sample events, the values extracted are emphasizedand have an “x” control. Any of the values extracted can be registeredas a negative example. A negative event selection can be undone using acontrol such as 1822.

FIG. 19 illustrates saving an extraction rule for subsequentapplication. A GUI 1900 implements the save step 808 in the structuredsequence.

The GUI 1900 can allow for the naming of the extraction rule and areview of pertinent information about the extraction rule, among otherthings. In this example, the extraction rule is saved in a file namedprops.conf. In other implementations the extraction rules can be savedto a database, a registry, or other data store. A name 1915 is given tothe extraction rule. The name of the extraction can be a list of thefield names 1975 or any other text preferred. Other pertinentinformation about the extraction rule, such as the owner 1925 andapplication 1935, can be entered. The GUI 1900 can also allow for thedefinition of permissions 1945 for the extraction rule. In this example,permissions regarding how the extraction rule will execute for theowner, the search application 1935, and in all other applications can beset.

The sourcetype 1955, selected at the beginning of extraction ruledevelopment process, is also displayed.

A sample event 1442 is displayed showing three field extractions 1515,1516, and 1517 that were chosen as positive examples for the extractionrule. The required text attribute 1985 indicates that “STP statusForwarding” is required text, which is evident in the regular expression1995. The field names 1975 of ‘b’ and ‘a’ (1997, 1998) also appear theregular expression 1995.

The extraction rule can be saved as part of a data model that representssets, subsets of events, and model-related field extraction rules. Inthe data model, the extraction rules are part of a late binding schema.A hierarchical data model can be used to simplify data for user analysisand reporting. In the data model, objects that reference the subsets canbe arranged in a hierarchical manner, so that child subsets of eventsare proper subsets of their parents. Fields available in parent sets ofdata are inherited by child subsets of data.

Disclosure Copied from Priority Applications

The operation of certain aspects of various embodiments will now bedescribed with respect to FIGS. 20-22. FIG. 20 illustrates oneembodiment of an architecture for use in managing variable dataselection of a representative data subset from a larger dataset.Architecture 2000 includes components within network device 400 usableto manage variable data selection and post-processing. Not all of thecomponents shown in FIG. 20 may be required to practice the subjectinnovations, and variations in the arrangement and type of thecomponents also may be made. As shown, architecture 2000 includesdataset 412, DSM 282, PPM 284, and network 102.

As discussed above, DSM 282 is configured to identify a variablerepresentative sampling of data as a resultant subset of data from thelarger dataset 412 that includes unstructured data. It is noted thatlarger dataset 412 may also include structured as well as unstructureddata. DSM 282 provides a GUI, which is described in more detail below.Briefly, however, the GUI enables a user to provide various dataselection parameters and/or criteria to DSM 282 for use inidentifying/selecting records from dataset 412 as the resultant subset.The user may, for example, indicate various types of processing to beperformed on at least some of the data within dataset 412 to generatedifferent types of resultant subsets. For example, the user may inputparameters/criteria, using the GUI, usable to identify a subset that isbased on one or more latest records, earliest records, diverse records,outlier records, random records, and/or combinations thereof. DSM 282,however, is not constrained to these subset types, or combinationsthereof, and others may also be included, DSM 282 may employ a processsuch as described in more detail below in conjunction with FIG. 22 toperform at least some of its actions based in part on the provided inputdataset(s) and parameters/criteria.

It should be noted that while a graphical user interface is disclosedherein, other embodiments may employ other mechanisms for enabling auser to perform actions, including, for example, a command lineinterface (CLI), or the like. Thus, in some embodiments, a CLI might beemployed to request a subset to be generated. One non-limiting,non-exhaustive example of such might include a command such as “%makesubset mybigdata.csv>subset.csv.” Clearly, other mechanisms may alsobe used.

Further, the resultant data from DSM 282 may be provided to PPM 284 foruse in further processing. It should be noted, however, the PPM 284 neednot be constrained to merely operating on resultant data from DSM 282.For example, PPM 284 may, in some embodiments, operate on data obtainedfrom any of a variety of sources, including directly from dataset, datareceived directly from one or more client devices, manually entereddata, or the like.

PPM 284 includes various post-processing components, including subsetanalyzer 2010, anonymizer 2011, and subset previewer 2012. As indicatedby the dashes within PPM 284, other post-processing components may alsobe included, and thus, subject innovations are not constrained to thoseshown. For example, a sharing component may be included that enablesusers to post-process and share at least some of the resultant data withone or more other network devices, data stores, or the like. Anothercomponent may include a saving component that is configured to save thereceived data, as well as various extraction rules, data types, columnvalues, filters, parameters, or any combination thereof, to permanentstorage for later application of the data.

Subset analyzer 2010 is configured to enable a user to perform variouspost analysis on the subset of data, including, for example, analysisfor generation of extraction rules, sorting rules, reporting rules, oreven storage rules. For example, using subset analyzer 2010, a usermight generate an extraction rule for the subset of data that isgenerated based on the clustering algorithm (e.g., for the outlierand/or diverse subtypes). Subset analyzer 2010 may then provide feedbackabout a percentage of events/records within some or all of the clustersfrom which data might be extracted using the extraction rule. Other postanalysis actions may also be performed, and therefore, subjectinnovations are not limited by the provided non-limiting, non-exhaustiveexamples of post analysis.

Anonymizer 2011 is configured to enable a user to perform variousactions that are directed towards depersonalizing the data. Informationwithin the data that may be construed as Personally IdentifiableInformation (PII), or otherwise private, confidential, or otherwise forlimited viewing, may be modified by anonymizer 2011 to remove such data.In some embodiments, because some of the data within the subset isunstructured data, anonymizer 2011 may be used to identify the location,type, and filter rules, for anonymizing the data. It should be noted.that while anonymizer 2011 may operate on the subset data, anonymizer2011 is not so limited. For example, anonymizer 2011 may analyze thesubset data in order to create anonymizer filters/rules that may then beapplied to at least some data within or obtained further from the largerdataset, such as dataset 412.

Subset previewer 2012 is configured to employ various extraction rulesthat may be generated based on an analysis of the received resultantdata. The extraction rules may then be used to further extract data fromthe resultant data subset, or from dataset 412.

FIG. 21 illustrates a logical flow diagram generally showing oneembodiment of a process for enabling real time display of event recordsand extracted values based on manual editing of a data field extractionrule. In some embodiments, process 2100 of FIG. 21 may be implemented byand/or executed on a single network device. In other embodiments,process 2100 or portions of process 2100 of FIG. 21 may be implementedby and/or executed on a plurality of network devices. In yet otherembodiments, process 2100 or portions of process 2100 of FIG. 21 may beimplemented by and/or executed on one or more blade servers. However,embodiments are not so limited and various combinations of networkdevices, blade servers, or the like may be utilized.

Process 2100 begins, after a start block, at block 2102, where aplurality of event records may be displayed. In some embodiments, aplurality of received event records may be displayed as a list ofrecords, such as is shown in FIG. 30A. In at least one of variousembodiments, block 2102 may employ embodiments to receive the pluralityof event records for display.

Process 2100 proceeds to block 2104, where an input from a user thatedits an extraction rule may be received. In at least one embodiment, aGUI may be employed to enable the user to edit an extraction rule. Inone non-limiting, non-exhaustive example, an extraction rule (e.g., apreviously generated or a newly generated extraction rule) may bedisplayed to the user in an editable text box. The user may then makeedits to the extraction rule by typing in the text box. However,embodiments are not so limited and other graphical interface objects maybe employed to enable a user to manually edit the extraction rule. In atleast one of various embodiments, block 2104 may employ embodiments toprovide an extraction rule, which may be edited by the user. In otherembodiments, the user may manually enter an extraction rule startingfrom scratch. In some embodiments, the extraction rule may be displayedto the user as source code, which the user may modify to edit theextraction rule.

Process 2100 continues next at block 2106, where the displayed eventrecords may be dynamically modified based on the edited extraction rule.In at least one embodiment, as the user edits the extraction rule, anemphasis of the field defined by the edited extraction rule for eachevent record may be modified in real time. For example, a highlightingof text in the event record (i.e., the extracted value) may be modifiedas the extraction rule is being edited that reflects the editedextraction rule. In at least one of various embodiments, block 2106 mayemploy embodiments to enable real time display of event records.

Process 2100 proceeds next to block 2108, where at least one value maybe extracted from each of the plurality of event records based on theextraction rule. In at least one of various embodiments, block 2108 mayemploy embodiments to extract values from each of the plurality of eventrecords.

Process 2100 continues at block 2110, where the GUI may be employed todynamically display the extracted values in real time. In at least oneembodiment, as the user is editing the extraction rule, the extractedvalues may change and those changes (e.g., the extracted values based onthe edited extraction rule) may be displayed in real time. In someembodiments, a list of unique extracted values may be displayed. In atleast one of various embodiments, block 2110 may employ embodiments todisplay unique extracted values. In some embodiments, statistics thatcorrespond to the extracted values may also be displayed in real time.

In any event, process 2100 proceeds next to decision block 2112, where adetermination may be made whether an edit to the data field extractionrule was received. In at least one embodiment, this determination may bebased on input from a user into the GUI, such as editing the extractionrule in an editable text box (e.g., as described at block 2104). If theextraction rule was edited, changed, and/or otherwise modified by theuser, then process 2100 may loop to block 2106; otherwise, process 2100may return to a calling process to perform other actions.

FIG. 22 illustrates a logical flow diagram generally showing oneembodiment of a process for enabling the filtering of event recordsbased on a selected extracted value. In some embodiments, process 2200of FIG. 22 may be implemented by and/or executed on a single networkdevice. In other embodiments, process 2200 or portions of process 2200of FIG. 22 may be implemented by and/or executed on a plurality ofnetwork devices. In yet other embodiments, process 2200 or portions ofprocess 2200 of FIG. 22 may be implemented by and/or executed on one ormore blade servers. However, embodiments are not so limited and variouscombinations of network devices, blade servers, or the like may beutilized.

In some embodiments, process 2200 may be employed after process 2000 or2100 is employed. For example, in at least one embodiment, process 2000may be employed to provide real time display of event records along withunique extracted values and their corresponding statistics. As describedin more detail below, in some embodiments, process 2200 may enable auser to filter the display of the event records based on a selection ofa unique extracted value.

Process 2200 begins, after a start block, at block 2202, where anextracted value may be selected from a plurality of displayed extractedvalues. In some embodiments, the selection may be of a unique extractedvalue, such as displayed at block 2012 of FIG. 20 and/or 2110 of FIG.21. In at least one of various embodiments, the selection of theextracted value may be received through a GUI. The GUI may be employedto enable a user to select the extracted value. In at least oneembodiment, the user may utilize a mouse or other pointing device toclick on and select an extracted value. In some other embodiments, auser may select the extracted value by clicking on an identified valuein an event record. However, embodiments are not so limited, and othermechanisms may be employed to enable a user to select an extractedvalue.

Process 2200 proceeds next to block 2204, where a subset of theplurality of event records may be determined based on the selectedvalue. In at least one embodiment, the subset of event records mayinclude those event records with a value (as extracted by the extractionrule) that is equal to and/or matches the selected value.

Process 2200 continues at block 2206, where the subset of event recordsmay be displayed. In at least one embodiment, block 2206 may employembodiments of block 2010 of FIG. 20 to display the filtered eventsbased on the extraction rule. For example, assume that 100 event recordsare displayed to a user (e.g., at block 2010 of FIG. 20), where a valueextracted from each event record is highlighted in the event record. Ifa user selects extracted value “A”, then of the 100 event records, thoseevent records with an extracted value of “A” may be displayed to a user,such that any remaining event records may be hidden and/or otherwisedistinguished from the event records with the extracted value of “A”. Inat least one embodiment, those event records that do not include anextracted value that matches the selected value may be hidden from view.

Process 2200 proceeds next at block 2208, where a display of theextracted values may be modified based the selected value. In someembodiments, the selected value may be emphasized (e.g., byhighlighting, underlining, and/or otherwise identifying the selectedvalue. In other embodiments, other extracted values (i.e., thenon-selected value) may be hidden, dimmed, or the like, to indicate thatthey were not selected to determine the subset of event records.

After block 2208, process 2200 may return to a calling process toperform other actions. In some embodiments, a user may be enabled toselect another extracted value, in which case, process 2200 may processthe newly selected extracted value. In other embodiments, the user mayde-select the selected value, which may re-display the extracted valuesfrom the plurality of event records.

It will be understood that each block of the flowchart illustration, andcombinations of blocks in the flowchart illustration, can be implementedby computer program instructions. These program instructions may beprovided to a processor to produce a machine, such that theinstructions, which execute on the processor, create means forimplementing the actions specified in the flowchart block or blocks. Thecomputer program instructions may be executed by a processor to cause aseries of operational steps to be performed by the processor to producea computer-implemented process such that the instructions, which executeon the processor to provide steps for implementing the actions specifiedin the flowchart block or blocks. The computer program instructions mayalso cause at least some of the operational steps shown in the blocks ofthe flowchart to be performed in parallel. Moreover, some of the stepsmay also be performed across more than one processor, such as mightarise in a multi-processor computer system. In addition, one or moreblocks or combinations of blocks in the flowchart illustration may alsobe performed concurrently with other blocks or combinations of blocks,or even in a different sequence than illustrated.

Accordingly, blocks of the flowchart illustration support combinationsof means for performing the specified actions, combinations of steps forperforming the specified actions and program instruction means forperforming the specified actions. It will also be understood that eachblock of the flowchart illustration, and combinations of blocks in theflowchart illustration, can be implemented by special purposehardware-based systems, which perform the specified actions or steps, orcombinations of special purpose hardware and computer instructions.

FIG. 26 illustrates one non-limiting, non-exhaustive example embodimentof a graphical user interface (GUI) usable to manage selection of arepresentative data subset from a larger dataset. GUI 2300 of FIG. 23may include many more or less components than those shown in FIG. 23.However, the components shown are sufficient to disclose an illustrativeembodiment for practicing the subject innovations. Moreover, variationsin the arrangement and type of the components may be made withoutdeparting from the spirit or scope of the subject innovations.

GUI 2300 may be configured to be displayed by any of a variety ofdisplay device components, including within a screen display deviceusable by various computing devices, including the client devices and/ornetwork devices described above. Further, GUI 2300 is not constrained byany particular software language, scripting tool, or the like, forgenerating the display of GUI 2300. Moreover, GUI 2300 is notconstrained to drop down, fill-ins, buttons, or the like, and virtuallyany other mechanism usable to receive and/or display userparameter/criteria selections may be employed, GUI 2300 also may employany of a variety of input selection mechanism, including, but notlimited to touch screens, voice recognition, mouse, keyboard, stylus, orthe like.

In any event, as shown in FIG. 23, GUI 2300 may includeparameter/criteria selections including data source type 2302, datasource 2304, subset type 2306, maximum records 2308, record sample 2310,as well as selections that enable post-processing, such as saveselection 2312, share selection 2314, and analyze selection 2316. Datasource type 2302 allows a user to specify a data source type that may befrom a data store, an index of records, a structured file (such as, forexample, CSV, XML, JSON files, or the like), from structured networkdata, or the like. Data source 2304 is configured to allow a user tospecify a source of the data, which may include, a type of data source(such as from a file, a source of data from that type (suchas/var/log/data.csv, or the like), as well as an index name when thesource is from an index, database parameters such as connectioninformation, tables, columns, or the like; a network address and/or portwhen the source is from a network source; a file or directory name whenthe source is from a file or directory; or the like. Subset type 2306 isconfigured to allow a user to input the desired selected subset typesobtained from the data. As such the user may select one or more ofdiverse subset, outlier subset, oldest record subset, newest recordsubset, and/or random record subset type. As discussed above, othersubtypes may also be provided. Further, as illustrated in FIG. 23, acombination subset type may also be selected. In some embodiments, adefault for the combination subset type includes representative subsetsfrom each of the other subset types. However, in other embodiments, auser might highlight or otherwise select combinations of two or more ofthe other subset types to generate other combinations. Maximum records2308 is directed towards allowing a user to set a limit on a number ofrecords to retrieve, at least initially, from the specified data source.In some embodiments, a user might also be allowed to input a limit on anumber of records to display within record sample 2310. In someembodiments, record sample 2310 might be configured to display samplesof records that are obtained from within the resultant subset sampling.However, in other embodiments, record sample 2310 might also allow auser to select for display at least some of the records that are used togenerate the resultant subset sampling. In other embodiments, there maybe an input that enables a user to define other selection criteria thatmight be usable for example in a filtering query. The input mightinclude keywords, phrases, Boolean, expressions, wildcards, or the like.Such selection criteria might then be usable in selecting record samplesfor display, in selecting records for further processing, or the like.

Post-processing may also be performed using various selectors, includingusing save selection 2312 to save the resultant subset, share selection2314 to share the resultant subset with other devices, and analyzeselection 616 to commence further analysis upon the resultant. subset,or other data. While these post-processor selectors are illustratedwithin GUI 2300, it should be understood, that they may also be providedthrough a differently structured GUI. Thus, GUI 2300 is not to beconstrued as limiting the subject innovations.

FIG. 24 shows a flow chart of one embodiment of a process usable tomanage variable representative sampling of data as a subset from alarger dataset that includes unstructured data. Process 2400 of FIG. 24may be executed by one or more processors, and/or through actionsperformed in part by a client device, or the like.

Process 2400 begins, after a start block, at block 2402 where dataselection parameters/criteria is received. In some embodiments, the dataselection parameters/criteria may be received from a user that mightemploy a GUI, such as described above in conjunction with FIG. 6.However, process 2400 is not so limited, and such data selectionparameters/criteria may be received using any of variety of othermechanisms.

In way event, the data selection parameters/criteria may includeinformation about a data source, any query constraints, a type of subsetdesired, and an amount of data desired (N). In some embodiments, thedata source might indicate that the input records are to be obtainedfrom dataset 412 of FIG. 4. However, process 2400 is not constrained tooperating on merely dataset 412, and any of a variety of other datasetsmay also be employed as input to process 2400.

Process 2400 moves next to decision block 2404, where a determination ismade whether the subset type to be used to obtain the resultant subsetis a combination subset. As an aside, in some embodiments, a defaultdesired subtype might also be used, when the user elects not to providea selection. In one embodiment, the default desired subtype might be acombination subset type that includes records from each of the availablesubset types. In any event, if the subtype process to be performed is acombination subtype, then processing flows to block 2406; otherwise,processing flows to decision block 2408.

At block 2406, the number of records obtained within the resultantsubset is computed as a split of the input N, such that records areobtained from each of the subtype processes identified in thecombination. For example, if the combination is to be obtained byperforming each of the five different processes (newest, oldest, random,diverse, and outliers), then N is, in one embodiment, recomputed asN=N/5. That is, a same number of records are obtained from each of thefive subtype processes. However, in other embodiments, other ratiosmight be used, including obtaining more records from one or more of thesubtypes than obtained from at least one other subtype in thecombination of subtypes. Processing then flows to decision block 2408.

At decision block 2408 a determination is made which one or more subtypeprocesses to perform. As noted, more than one of the subtype processesmay be performed. For example, all of the identified subtype processesmight be performed. Thus, in that instance, processing flows to blocks2410, 2412, and 2416. Such processing might be performed concurrently.However, in other embodiments, at least some of the selected subtypeprocess might be performed serially.

In any event, when one or more of newest or oldest subtype processes areto be performed, processing flows to block 2410. When the random subtypeprocess is to be performed, processing flows to block 2412; and when oneor more of diverse or outlier subtype processes are to be performed,processing flows to block 2416.

At block 2410, for newest subtypes, N most recent or current records areretrieved or otherwise extracted from the input set of records. That is,a query might be performed on the data source for the N newest records.For oldest subtype processing, a query of the data source may beperformed to retrieve a subset of records that contains N oldestrecords. Such queries may be performed by searching the data input for afield indicating a time in which the data was received by from a clientdevice for storage. Such field might be added during receipt from theclient device, or might be a known location within a record. Where bothnewest and oldest subtypes are to be obtained, such actions may beconcurrently performed within block 2410, or performed serially. Ineither event, processing then flows to decision block 2434.

At block 2412, a random subtype subset sampling is to be obtained. Itshould be understood that any of a variety of criteria may be employedto define randomness, including, but not limited to generating asampling record selection based on a pseudo-number generator, a valueobtained from a purely random source, or the like.

In at least one embodiment, for example, records may be retrieved fromwithin the data source a multiple (e.g., 50) of N, the desired returnedsubset to retrieve. That is −50*N records might be retrieved from thedata source. Then, a random subset N records might be extracted from the50*N records to generate the random subset. Thus, as illustrated, atblock 2412, a multiple of N records is obtained. As an aside, it shouldbe clear to one of ordinary skill in the art that any multiple of Nmight be selected, and therefore, 50 is merely a non-limiting example.Processing then flows to block 2414, where N random records are obtainedfrom this extracted subset to generate a random subtype sampling.Processing then flows to decision block 2434.

At block 2416, for diverse and/or outlier subtypes, a multiple of Nrecords is retrieved from the data source. Again, the multiple may bevirtually any non-negative value greater than zero that is directedtowards retrieving a whole number of records. Processing then flows toblock 2418.

At block 2418, any of a variety of clustering techniques may be appliedto the retrieved records. In some embodiments, the clustering techniqueused might be an unsupervised clustering technique, where the task is todevelop classification and sorting of the records without regard to apredefined number of groups or clusters to be generated. Suchunsupervised clustering techniques seek to identify similarities betweenportions of the data within the records in order to determine whetherthe records can be characterized as forming a group. Such groups aretypically also known as clusters. As noted, any of a variety ofunsupervised clustering techniques may be employed, including but notlimited to k-means, kx-trees, density estimation, self-organizing mapmodeling (SOM), adaptive resonance theory models (ART), as well as otherfeature extraction techniques. Further, the similarity may be based onany one or more fields or portions of data within the records. In someembodiments, the portions used might be predefined. However, in otherembodiments, additional analysis might be performed to select whichportion or portions of the records to use in creating the clusters.Further, clustering may be based on one or more column values, termsand/or phrases with a value or event independent of a given column,punctuation within column values, or the like. For example, the recordsmay be machine data that is generated by code that generates recordswith similar punctuations but having different terms. For example, thefollowing three records have different text:

00:02:35, 181 INFO [Processor10] Clickthruy 10.0.0.5-ApplicationID isCA7

00:02:35, 181 DEBUG [Processeor111] Subscription 10.0.2.1Subscribe-678/749/139-

00:02:39, 033 INFO [Processor24]Message 10.0.1.1MessageOpened-4928/12664-

However, each has similar punctuation:

::,[ ] . . . -

::,[ ] . . . -//-

::,[ ] . . . -/-

While unsupervised clustering techniques are typically directed towardsgenerating one or more clusters from the records, absent knowing apriori a predefined number of clusters to be created, other clusteringtechniques may also be used. Thus, supervised clustering techniques mayalso be used, where the number of clusters or groupings might bepredefined. In using supervised clustering techniques, in someembodiments, the number, k, of the resulting clusters might be iteratedupon, until some threshold criteria are satisfied. For example, a degreeof dissimilarity across each cluster is above a threshold, might be usedto determine when to stop iterating. The outcome of such iterationsmight then provide a value for k.

In any event, as noted, block 2418 results in the generation of one ormore clusters of the retrieved records. At block 2418, a number ofrecords in each cluster may vary, thus, at block 2418, each cluster maybe assigned some identifier, where the identifier is usable to indicatewhich cluster a record belongs. A cluster size for each cluster andtheir identifier may be saved. Continuing to block 2420, a subset of therecords from each cluster may be selected, based on any of a variety ofcriteria. For example, each record selected from a cluster may be basedon a most similar criteria, or most representative of the cluster, orany of a variety of other criteria. Any number of records from theclusters may be selected. For example, three records may be returned.However, it should be noted that block 2420 may, in some embodiments, beoptional, and all records for each cluster might be selected andretained for later analysis.

Process flow then continues to decision block 2422, where adetermination is made whether the desired subtype is the diverse subtype(or the outlier subtype). When the desired subtype is the diversesubtype, processing flow to block 2424; otherwise, processing flows toblock 2426. For combination subtypes that include both outlier anddiverse subtypes, processing might flow to both blocks 2424 and 2426.

At block 2424, the clusters are sorted by cluster size in descendingcluster size order. At block 2426, the clusters are sorted by ascendingcluster size order. The result is that the records are sorted based onthe cluster size, in most common cluster first for the diverse subtype,and least common records for the outlier subtype. The following providesone non-limiting, non-exhaustive example implementation of such sortingusing a search processing language (SPL):

sourcetype=car reports

|head25000

|cluster t=0.7 showcount=true labelonly=true field=MYCOLUMN

|dedup 3 cluster_label

|sort 500-cluster_count

|sort_time

Other implementations may also be employed. Therefore, the above exampleshould not be construed as limiting the subject innovations. In anyevent, the above example search would retrieve the 25000 most recentrecords, clusters the records by MYCOLUMN, keeps up to three records percluster, keeps 500 records from the most common clusters (diversesubtype), and then optionally resorts the records into time order.

Process for both blocks 2424 and 2426 then flow to decision block 2428,where a cluster iteration analysis is performed to determine whether thenumber of clusters are greater than a defined threshold number for thediverse subtype. When the subtype is the outlier subtype, one embodimentmight include an ‘or’ evaluation, of whether the least popular clustersare more common than another threshold. Should the cluster iterationanalysis indicate that the number of cluster is not greater than athreshold, or (at least for outlier evaluations) that the least popularclusters are not more common than another threshold, processing flows toblock 2432, where additional records are retrieved from the data source.In some embodiments, for example, if the initial. subset retrieved 100Krecords, then the process might retrieve an additional 100K records. Insome embodiments, if not enough clusters are retrieved, indicating thateverything might be fairly homogeneous, then more events can beretrieved until a threshold is met, and there is determined to besufficient diversity. Processing then branches back to block 2418 tocontinue cluster performance until the cluster iteration analysis issatisfied.

When the cluster iteration analysis is satisfied, at decision block2428, processing then flows to block 2430, where a first N set ofrecords are retained. Processing then flows to decision block 2434,where a determination is made whether subtype processing is completed.Where the desired subtype processing is the combination subtype,processing might then branch back to decision block 2408, until each ofthe subtypes with the combination subtype has generated a respective Nnumber of records (or weighted number of records), which may then becombined to generate the resultant sampling subset of records.Processing would then be completed, and would return to another process.

As seen above for the diverse subtype, the resulting records may includea few (e.g., three) instances of the most common clusters, and given Nrecords, many diverse types of records may be in the subset, covering alarge portion of the types of records likely in the full dataset. Forexample, given a database of car ownership records in the United States,it may be desired to generate a subset of 500 records that represent themost common cars. By retrieving 100K records, clustering the 500 recordsby car model (or MPG, weight, cost, or any of a variety of othercriteria), keeping three instances of the most common models, the 500records in the resultant subset would that a majority of the types ofcars in the dataset would be represented.

As discussed above, for the outlier subtype, the subset is made up ofrecords from the least common types of records. By keeping the recordsfrom the rarest cluster, the resulting records are intended to representthe outlier records. While the goal of the diverse subtype is torepresent the most common records (e.g., 95%), the goal of the outliersubtype is to represent the rare (e.g., 5%) or unusual records. To usethe same example as above, given a dataset of all car ownership recordsin the United States, a desire is to generate a subset of 500 recordsthat represent the most obscure cars. By retrieving 100K records,clustering by car model (or other criteria), keeping three instances ofthe least common models, the 500 records would have uncommon cars. Withkeeping just about 500 records, most of the most obscure cars areexpected to be represented. While this might not find all of the mostobscure cars in the full dataset, as this would require processing overthe full dataset, it is anticipated to provide a reasonablerepresentative sampling of the outliers.

However, other mechanisms may also be used to obtain outliers, ordiverse subtypes. For example, statistical methods may be applied toretain those outlier/diverse records based on a statistical confidencelevel desired. For example, using various statistical methods, theinitial number N of records retrieved might be determined based on aconfidence level. Techniques may also be used that include keepingrecords that have column values outside of a norm in a statisticaldistribution, such as more than two standard deviations from the mean,or in commonality (e.g., more rate than other values), or the like.

FIG. 25 shows a flow chart of one embodiment of a process for analyzingdata. Process 2500 begins, after a start block, at block 2502 where oneor more data streams are received. At block 2504, the one or more datastreams are parsed into a plurality of events. At block 2506, a set ofthe plurality of events are selected. At block 2508, a clusteringalgorithm is performed on the set of events to generate a plurality ofclusters. At block 2510, a number is determined based on the clusters.At decision block 2512, it is determined whether the number is less thana threshold number. If so, process 2500 continues to block 2514, whereanother set of events is retrieved from the plurality of events. Atblock 2516, the set of events and the other set of events are combinedto produce a combined set of events. Process 2500 then returns to block2508. When the number is determined not to be less than the thresholdnumber, process 2500 continues to block 2518, where a subset of eventsare selected from the plurality or second plurality of clusters. Atblock 2520, one or more of the events in the subset are displayed.

As seen above, using the combination subtype would result in obtainingsubsets from two or more of the above discussed subtype processes. Thenumber of records in results from each subtype would then total to thedesired number of records (e.g. 500). Use of the combination subtype isdirected towards enabling a user to test various hypotheses, such aswhether there are anomalies in the earliest or latest data, in importantcommon types of records, or in obscure types of records. A combinationof subtypes that include random records might assist in making a subsetthat might be usable for automated tasks, such as validating thatpatterns match records in the data (e.g., such as might be used forgenerating extraction rules, anonymizing rules, or the like); thatexpected records occur, or that expected records do not occur; that thelatest data is similar, or not, to the oldest data; or any of a varietyof other post-processing analysis.

The operation of certain aspects of the technology disclosed will now bedescribed with respect to FIGS. 26-28. FIG. 26 illustrates a logicalflow diagram generally showing one embodiment of an overview process forenabling real time display of fields based on previously providedextraction rules. In some embodiments, process 2600 of FIG. 26 may beimplemented by and/or executed on a single network device. In otherembodiments, process 2600 or portions of process 2600 of FIG. 26 may beimplemented by and/or executed on a plurality of network devices. In yetother embodiments, process 2600 or portions of process 2600 of FIG. 26may be implemented by and/or executed on one or more blade servers.However, embodiments are not so limited and various combinations ofnetwork devices, blade servers, or the like may be utilized.

Process 2600 begins, after a start block, at block 2602, where aplurality of event records may be provided. In some embodiments, theevent records may be provided by a plurality of different computingdevices, such as client devices. In at least one embodiment, theplurality of event records may be a sample subset of a larger dataset ofevent records dataset. In some embodiments, the larger dataset of eventrecords may be associated with one or more users and/or clients. Asdescribed above, the event records may be structured data orunstructured data. Additionally, the event records may include machinedata.

Process 2600 proceeds next to block 2604, where data field extractionrules may be provided. In some embodiments, a plurality of extractionrules may be provided. The provided extraction rules may define a fieldwithin the plurality of event records from which to extract data (e.g.,a field value). Accordingly, in some embodiments, the extraction rulemay define a field within the event records independent of apredetermined and/or predefined structure of the event records.Extraction rules may be provided independent of one another. In at leastone of various embodiments, two or more extraction rules may definefields that may be distinct and/or separate fields. In otherembodiments, two or more extraction rules may define fields thatpartially or completely overlap each other.

In some embodiments, where fields overlap, an extraction rule may definea subfield of another field. In at least one embodiment, the other fieldmay be defined by another extraction rule and/or may be a structuredand/or predefined field. For example, Extraction Rule A may define afield as “Server_ID”, which may include a name of a server and anaddress of the server. Additionally, Extraction Rule B may define afield as “Server_name”, which may include the name of the server, butnot the address of the server. In this example, Extraction Rule B maydefine a subfield of the field defined by Extraction Rule A; orExtraction Rule B may be referred to as a sub-rule to Extraction Rule A.

In various embodiments, one or more extraction rules may be provided.Extraction rules may be automatically generated, manually entered by auser, previously provided/created, provided by another system, or thelike, or any combination thereof. In at least one embodiment, automaticgeneration of an extraction rule may be based on a value selected froman event record. In some embodiments, a graphical user interface (GUI)may be employed to enable a user to select desired text of an eventrecord. From the selected text, pattern recognition algorithms may beemployed to automatically generate the extraction rule. In at least oneembodiment, the extraction rule may be a regular expression.

In another embodiment, the GUI may be employed to enable the user tomanually input the extraction rule. In at least one embodiment, the usermay enter a regular expression or other extraction rule into an editableinput text box in the GUI to define a field within the event recordsfrom which to extract data.

In yet other embodiments, the user may utilize the GUI to manually editextraction rules (either previously automatically generated extractionrules or previous user-entered extraction rules) and receive a real timedisplay of newly extracted values, statistics that correspond to theextracted values, changes to a display of the event records, or the likeor any combination thereof. Real time display of field values based onmanual editing of extraction rules is described in more detail below inconjunction with FIG. 6.

In some embodiments, the GUI may be employed to enable a user to providea field name for the extraction rule (e.g., the field defined by theextraction rule). In other embodiments, the system may automaticallydetermine a field name for the extraction rule. In at least one suchembodiment, the system may employ the extraction rule to extract a valuefrom one or more event records. The field name may be determined basedon this value, such as, for example, a datatype of the extracted value(e.g., an integer), a format of the extracted value (e.g., a phonenumber, URL, time/date format), or the like. In various embodiments, theextraction rule may be automatically generated, manually input by auser, or the like, or any combination thereof.

In any event, process 2600 continues next at block 2606, where the GUImay be employed to display the event records based on the providedextraction rules in real time. In at least one embodiment, the pluralityof event records may be displayed to the user in virtually any order,such as, most recent, latest, or the like.

An embodiment of a process for displaying event records based onpreviously provided extraction rules is described in more detail belowin conjunction with FIG. 6. Briefly, however, in at least oneembodiment, displaying an event record based on an extraction rule mayinclude emphasizing the fields defined by the extraction rules (e.g.,the extracted value) in the event record. examples of such emphasizingmay include, but are not limited to, dimming, highlighting, underlining,bolding, striking through, italicizing, displaying different font,displaying different font size, displaying different color, displayingdifferent transparency, including parenthesis around the text, and thelike. FIGS. 30B and 30C illustrate embodiments of real time display ofevent records where values associated with one or more fields defined byone or more extraction rules are emphasized.

In some other embodiments, fields defined by different extraction rulesmay be emphasized in a same way or different ways. For example, in oneembodiment, text of each defined field may be emphasized by displayingthe text in a single font color. However, such emphasizing may make itdifficult for a user to distinguish between fields or to determine ifmultiple fields overlap. In some other embodiments, each field may beemphasized differently. For example, in one embodiment, text of onedefined field may be emphasized by displaying the text in one font, andtext of a different defined field may be emphasized by displaying thistext in a different font. However, embodiments are not so limited andother types of display emphasizing may be employed.

In some embodiments, real time display of the event records may includedisplaying the event records based on the provided extraction rules asthe extraction rules are being provided, entered, and/or edited by auser. Accordingly, the GUI may update a display of each event record andan indication of each extracted value in near real time as an extractionrule is edited or generated. It should be understood that real time ornear real time display of data, as used herein, may include a delaycreated by some processing of the data, such as, but not limited to, atime to obtain an extraction rule, a time to determine text to emphasizebased on the extraction rules, or the like.

Process 2600 proceeds next at block 2608, where a portion of at leastone event record may be selected. The portion of the event record mayinclude a subset, part, and/or area of a displayed event record. Forexample, in at least one of various embodiments, the portion may be astring of one or more characters, numbers, letters, symbols, whitespaces, or the like. However, the selected portion is not limited to asubset of the displayed event record, but in another embodiment, theportion may include the entire displayed event record. In some otherembodiments, the portion may span multiple event records.

In some embodiments, the portion may include one or more fields definedby one or more extraction rules. In at least one such embodiment, theportion may be an emphasized area of the event record, such as fieldsthat are emphasized in each event record (e.g., as described at block2606). For example, text of an event record may be emphasized becausethat text is associated with at least one field defined by at least oneextraction rule. In this example, the portion selected by the user maybe the emphasized text. FIG. 30C illustrates an embodiment of emphasizedportions of an event record based on previously provided extractionrules.

In at least one of various embodiments, a GUI may be employed to enablea user to select the portion of the event record. The user may selectthe portion of the event record by clicking on the portion of the eventrecord, highlighting text of an event record, rolling over ormousing-over an area of the event record, or the like. For example, inat least one embodiment, a user may click on an emphasized portion of anevent record to select it. In another embodiment, the user may roll apointer over the emphasized portion of the event record to select it. Inyet other embodiments, the user may utilize a text selection mechanismto highlight and select text of the event record to be the selectedportion of the event record. These embodiments are non-limiting andnon-exhaustive and other mechanisms may be employed to enable a user toselect a portion of at least one event record.

Process 2600 continues at block 2610, where extraction rules associatedwith the selected portion may be displayed, which is described in moredetail below. Briefly, however, in at least one of various embodiments,a window or pop-up box may open to display the associated extractionrules. In some embodiments, a name of the associated extraction rulesmay be displayed. In at least one such embodiment, this name may be aname of the field defined by the extraction rule. In other embodiments,a value of each field defined by the extraction rule may be displayed.In at least one such embodiment, these values may be values extractedfrom the event record (from which the portion was selected to determinethe associated extraction rules) using the associated extraction rules.

In any event, process 2600 proceeds to decision block 2612, where adetermination may be made whether another portion of an event record isselected. In at least one embodiment, a user may select another portionof a same or different event record. Embodiments of block 2608 may beemployed to receive a selection of another portion of an event record.If another portion is selected, then process 2600 may loop to block 2610to display extraction rules associated with the other selected portion;otherwise, process 2600 may return to a calling process to perform otheractions.

FIG. 27 illustrates a logical flow diagram generally showing oneembodiment of a process for displaying event records that emphasizesfields based on previously provided extraction rules. In someembodiments, process 2700 of FIG. 27 may be implemented by and/orexecuted on a single network device. In other embodiments, process 2700or portions of process 2700 of FIG. 27 may be implemented by and/orexecuted on a plurality of network devices. In yet other embodiments,process 2700 or portions of process 2700 of FIG. 27 may be implementedby and/or executed on one or more blade servers. However, embodimentsare not so limited and various combinations of network devices, bladeservers, or the like may be utilized.

Some markup languages, such as HTML or XML, do not allow overlapping tagpairs. This type of limitation can make it difficult to displayindividual fields that overlap one another, where each field may bedefined by a tag pair that may overlap another tag pair. Process 2700describes embodiments for displaying overlapping and/or sub-containingsections of text (e.g., overlapping fields and/or sub-fields) within anoverlapping tag-pair-limited mark-up language, such as, but not limitedto HTML or XML. Process 2700 further describes embodiments that enablethe display of overlapping fields while preserving individualinformation segments (e.g., field values) contained within each field ortag pair.

Process 2700 begins, after a start block, at block 2702, where an eventrecord may be selected. In at least one embodiment, event records may berandomly selected from a plurality of event records (e.g., the pluralityof event records provided at block 502 of FIG. 5). In anotherembodiment, event records may be selected in a predetermined order, suchas chronologically (e.g., based on a timestamp), reversechronologically, alphabetically, or the like. In yet other embodiments,a field, such as a field defined by an extraction rule, may be utilizedto determine an order of selecting event records. For example, a fieldmay define a server identifier and event records may be selected basedon the server identifier. However, other mechanisms and/or algorithmsmay be employed for determining which event record to select.

Process 2700 proceeds at block 2704, where an extraction rule may beselected. In at least one embodiment, the extraction rule may beselected from a plurality of extraction rules that were previouslyprovided (e.g., created, stored, or the like). The plurality ofextraction rules may have been automatically generated, manuallycreated, or the like, such as is described at block 504 of FIG. 5.

Process 2700 continues at block 2706, where a field defined by theselected extraction rule may be determined. In at least one embodiment,this determination may include using the selected extraction rule todetermine and/or identify text and/or a value of the selected eventrecord that corresponds to the field defined by the selected extractionrule. In some embodiments, this text and/or value (or a location andsize of this text/value within the selected event record) may be atleast temporarily maintained/stored and used to display the selectedevent record at block 2710.

In any event, process 2700 proceeds to decision block 2708, where adetermination may be made whether another extraction rule may beselected. In some embodiments, another extraction rule may be selectedfrom a plurality of extraction rules until each of the plurality ofextraction rules is selected. If another extraction rule may beselected, then process 2700 may loop to block 2704 to select anotherextraction rule; otherwise, process 2700 may flow to block 2710.

At block 2710, the selected event record may be displayed with anemphasis of each determined field (e.g., as determined at block 2706).As described above, in at least one embodiment, a display of text ofeach determined field may be emphasized within the selected eventrecord. In some embodiments, each determined field may be emphasized inthe same way, such as, for example, all may be emphasized with a lightblue highlight. In other embodiments, each determined field may beemphasized in a different way, such as, for example, each determinedfield may be enclosed in different colored parentheses. However,embodiments are not so limited, and other mechanisms for emphasizing thedetermined fields in the selected event record may be employed.

In some embodiments, two or more determined fields may overlap. In atleast one such embodiment, the corresponding text/values may be combinedand emphasized together as a super set field, such that each overlappingfield may not be individually distinguished from one another.Accordingly, in some embodiments, the combined text may be employed toemphasize a plurality of fields in a super set field that is defined bya plurality of different extraction rules.

In at least one embodiment, a start and end character location of thedetermined fields within the selected event record may be utilized todetermine if fields overlap. For example, assume in the selected eventrecord, Field_A has a start character location of 5 and an end characterlocation of 10 and Field_B has a start character location of 7 and anend character location of 15. In this example, a combined text fromcharacter location 5 to 15 may be emphasized.

In some other embodiments, the start and end character location ofmultiple determined fields may be compared to determine a super set ormost inclusive field. For example, assume the above example is expandedto include Field_C that has a start character location of 5 and an endcharacter location of 22. In this expanded example, the combined textthat may be emphasized may be from character location 5 to 22.Additionally, in this expanded example, Field_A and Field_B may besub-fields of Field_C (and may or may not be sub-fields of each other).

In any event, process 2700 continues next at decision block 2712, wherea determination may be made whether another event record may beselected. In some embodiments, another event record may be selected froma plurality of event records until each of the plurality of eventrecords is selected and displayed. If another event record may beselected, then process 2700 may loop to block 2702 to select anotherevent record; otherwise, process 2700 may return to a calling process toperform other actions.

FIG. 28 illustrates a logical flow diagram generally showing oneembodiment of a process for displaying previously provided extractionrules associated with a selected portion of an event record. In someembodiments, process 2800 of FIG. 28 may be implemented by and/orexecuted on a single network device. In other embodiments, process 2800or portions of process 2800 of FIG. 28 may be implemented by and/orexecuted on a plurality of network devices. In yet other embodiments,process 2800 or portions of process 2800 of FIG. 28 may be implementedby and/or executed on one or more blade servers. However, embodimentsare not so limited and various combinations of network devices, bladeservers, or the like may be utilized.

Process 2800 begins, after a start block, at block 2802, where a portionof an event record may be selected. In at least one of variousembodiments, block 2802 may employ embodiments of block 508 to select aportion of an event record.

Process 2800 proceeds to decision block 2804, where a determination maybe made whether there is one or more extraction rules associated withthe selected portion that was not previously selected at block 2806. Insome embodiments, process 2800 may proceed through blocks 2806, 2808,2810, and 2812 once for each extraction rule associated with theselected portion. If one or more extraction rules are associated withthe selected portion, then process 2800 may flow to block 2806;otherwise, process 2800 may return to a calling process to perform otheractions.

At block 2806, an extraction rule associated with selected portion maybe selected. In at least one embodiment, the selection of an extractionrule may be random, in a predetermined order, or the like.

Process 2808 proceeds next to block 2808, where an identifier of theselected extraction rule may be displayed. In some embodiments, thisidentifier may include a name of the field defined by the selectedextraction rule. In other embodiments, this identifier may be anextraction rule name. In yet other embodiments, the selected extractionrule itself may be displayed.

Process 2800 continues at block 2810, where the selected extraction rulemay be used to extract a value from the event record from which theselected portion was selected. In at least one of various embodiments,the selected extraction rule may be applied to the event records todetermine data to extract from the event record. The extracted data fromthe event record may be the particular value for the event record forthe field defined by the selected extraction rule. For example, if theselected extraction rule defines a field as the characters between afirst set of single brackets, then the value for the event record “Dec17 10:35:38 ronnie nslcd[23629]: [40f750] passwd entry uid” may be“23629”.

In any event, process 2800 proceeds at block 2812, where the extractedvalue may be displayed. In at least one embodiment, the extracted valuemay be displayed next to or in conjunction with the identifier of theselected extraction rule. An example of a GUI displaying an identifierof the selected extraction rule and a corresponding extracted value isillustrated in FIGS. 30A-30B.

After block 2812, process 2800 can loop to decision block 2804 todetermine if there is another extraction rule associated with theselected portion that was not previously selected at block 2806.

In another enablement illustrated in FIG. 29, process 2900 begins, aftera start block, at block 2902, where a plurality of event records may beprovided. In some embodiments, the event records may be provided by aplurality of different computing devices, such as client devices. In atleast one embodiment, the plurality of event records may be a samplesubset of a larger dataset of event records dataset. In someembodiments, the larger dataset of event records may be associated withone or more users and/or clients. As described above, the event recordsmay be structured data and/or unstructured data. Additionally, the eventrecords may include machine data.

Process 2900 proceeds next to block 2904, where a data field extractionrule may be provided. In various embodiments, the extraction rule may beautomatically generated, manually input by a user, previouslyprovided/created, provided by another system, or the like, or anycombination thereof. The extraction rule may define a field within theplurality of event records from which to extract data (e.g., a fieldvalue). Accordingly, in some embodiments, the extraction rule may definea field within the event records independent of a predetermined and/orpredefined structure of the event records.

In at least one embodiment, automatic generation of an extraction rulemay be based on a value selected from an event record. In someembodiments, a graphical user interface (GUI) may be employed to enablea user to select desired text of an event record. From the selectedtext, pattern recognition algorithms may be employed to automaticallygenerate the extraction rule. In at least one embodiment, the extractionrule may be a regular expression.

In another embodiment, the GUI may be employed to enable the user tomanually input the extraction rule. In at least one embodiment, the usermay enter a regular expression or other extraction rule into an editableinput text box in the GUI to define a field within the event recordsfrom which to extract data. In yet other embodiments, the user mayutilize the GUI to manually edit extraction rules—either previouslyautomatically generated extraction rules or previous user-enteredextraction rules.

As extraction rules are being generated and/or edited, the GUI maydisplay real time updates of newly extracted values, statistics thatcorrespond to the extracted values, changes to a display of the eventrecords, or the like, or any combination thereof. Various embodiments ofreal time display of field values based on manual editing of extractionrules is described in more detail below.

In some embodiments, the GUI may be employed to enable a user to providea field name for the extraction rule (e.g., the field defined by theextraction rule). In other embodiments, the system may automaticallydetermine a field name for the extraction rule. In at least one suchembodiment, the system may employ the extraction rule to extract a valuefrom one or more event records. The field name may be determined basedon this value, such as, for example, a datatype of the extracted value(e.g., an integer), a format of the extracted value (e.g., a phonenumber, URL, time/date format, or the like), or the like. In variousembodiments, the extraction rule may be automatically generated,manually input by a user, or the like, or any combination thereof.

In any event, process 2900 continues next at block 2906, where a valuemay be extracted from each of the plurality of event records based onthe extraction rule. In at least one of various embodiments, theextraction rule may be applied to each of the plurality of event recordsto determine what data to extract from each event record. The extracteddata from a given event record may be the particular value for thatevent record for the field defined by the extraction rule. For example,if an extraction rule defines a field as the characters between a firstset of single brackets, then the value for the event record “December 1710:35:38 ronnie nslcd[23629]: [401750] passwd entry uid” may be “23629”.

Proceeding to block 2908, at least one statistic may be determined foreach unique extracted value. In at least one embodiment, a uniqueextracted value may be an extracted value that is different than anotherextracted value, regardless and/or independent of a number of instancesthat a value is extracted from the plurality of event records. Forexample, assume the extracted values from a six event records includes[“Bob”, “Bob”, “Ralph”, “Bob”, “John”, “Ralph”]. The unique extractedvalues may be “Bob”, “Ralph”, and “John”.

Based on the extracted unique values, statistics may be determined. Inat least one embodiment, a statistic for a unique value may be a totalnumber of times the unique value occurs in the plurality of records. Inanother embodiment, a statistic for a unique value may be a percent of anumber of times the unique value occurs compared to a number of recordsin the plurality of records. In yet another embodiment, a statistic fora unique value may be a percent of a number of times the unique valueoccurs compared to a number of extracted values. This number may bedifferent than a number of records in the plurality of records if theextraction rule does not result in a value being extracted from at leastone event record. For example, assume an extraction rule defines a fieldas the characters between a first set of single brackets. If an eventrecord does not include single brackets, then no value may be extracted.However, embodiments are not limited to these types of statistics andother statistics and/or metrics may also be employed.

Process 2900 continues next at block 2910, where the GUI may be employedto display the event records based on the extraction rule in real time.In at least one embodiment, the plurality of event records may bedisplayed to the user in virtually any order, such as, most recent tolatest or the like. In at least one embodiment, displaying an eventrecord based on an extraction rule may include emphasizing the fielddefined by the extraction rule (e.g., the extracted value) in the eventrecord. Examples of such emphasizing may include, but are not limitedto, highlighting, underlining, and/or otherwise identifying the valueextracted from the event record. FIG. 30B illustrates one embodiment ofreal time display of event records, where values extracted based on anextraction rule are highlighted. In some other embodiments, a pluralityof extraction rules may be employed for the plurality of event recordsand each corresponding extracted value may be emphasized (in a similaror different manner). In at least one embodiment, the values extractedfrom multiple extractions rules may be distinct and/or separate, and/ormay partially or completely overlap.

In some embodiments, real time display of the event records may includedisplaying the event records based on an extraction rule as theextraction rule is being provided, entered, and/or edited by a user.Accordingly, the GUI may update a display of each event record and anindication of each extracted value in near real time as an extractionrule is edited/generated.

Process 2900 proceeds next at block 2912, where the GUI may be employedto enable real time display of the unique extracted values and the atleast one corresponding statistic. In some embodiments where multipleextraction rules are employed, a set of unique extracted values andcorresponding statistics may be displayed for each distinct extractionrule.

In some embodiments, real time display of the unique extracted valuesand the at least one corresponding statistic may include displaying theunique extracted values and the at least one corresponding statistic asthe extraction rule is being provided, entered, and/or edited by a user.Accordingly, the GUI may update a display of a list of unique extractedvalues and the at least one corresponding statistic in near real time asan extraction rule is edited/generated.

It should be understood that real time or near real time display ofdata, as used herein, may include a delay created by some processing ofthe data, such as, but not limited to, a time to generate an extractionrule, a time to apply the extraction rule to the plurality of eventrecords, a time to calculate corresponding statistics, and/or the like.

Process 2900 may continue at decision block 2914, where a determinationmay be made whether a new data field extraction rule has been provided.In at least one embodiment, a new data field extraction rule may beautomatically provided. In another embodiment, a user may edit apreviously provided extraction rule. If a new extraction rule isprovided, process 2900 may loop to block 2906; otherwise, process 2900may return to a calling process to perform other actions.

FIGS. 30A-30C illustrate non-exhaustive examples of a use case ofembodiments of a graphical user interface that may be employed to enablea user to create extraction rule and to obtain real time display ofextracted values.

FIG. 30A illustrates a non-exhaustive example of a use case of anembodiment of graphical user interface that may be employed to enable auser to create extraction rule and to obtain real time display ofextracted values. Graphical user interface (GUI) 3000A may includemultiple viewing windows and/or sections that each display informationto a user. For example, GUI 3000A may include input 3002, input 3006,extraction rule preview 3004, records 3008, and extracted values 3010.

Records 3008 may display each event record that is determined based oninputs 3002 and 3006. Input 3002 may enable a user to input a datasource (e.g., a specific database) and/or a data type (e.g., system logdata). As illustrated, input 3002 may include one or more pull downmenus of available options of the data source and/or data type. However,other menus, lists, windows, or interfaces may also be employed. Input3006 may enable the user to define a specific filter to apply the eventrecords (e.g., the user may filter the event records to display thoseevent records that were recorded on a particular day). In otherembodiments, input 3006 may enable a user to select how the eventrecords are selected for display. In at least one embodiment, eventrecords 3008 may include a subset and/or sampling of a lager data set.For example, input 3006 may be used to select that event records 3008includes a predetermined number (e.g., 100) of the latest event records.However, other result types may be used, such as oldest, most popular,least popular, or the like, or any combination thereof.

Extraction rule preview 3004 may display instructions to a user forcreating an extraction rule. For example, the user may highlight and/orselect text in an event record in records 3008 to have an extractionrule automatically created. In another example, the user may manuallyenter an extraction rule (e.g., by clicking on the “Create extractionrule” button, an editable text box may open or become visible where theuser can manually input an extraction rule). Extraction rule preview3004 may display the extraction rule after it is created, such as isshown in FIG. 30B. Additionally, the user may be enabled to save theextraction rule for additional processing of event records and extractedvalues.

Extracted values 3010 may show unique values that are extracted fromevent records 3008 based on an extraction rule provided by extractionrule preview 3004. As illustrated, extracted values 3010 may be emptybecause no extraction rule has been provided.

FIG. 30B illustrates a non-exhaustive example of a use case of anembodiment of a graphical user interface where an extraction rule hasbeen provided. GUI 3000B may be an embodiment of GUI 3000A from FIG.30A.

Extraction rule preview 3004 may display the provided extraction rule.In at least one embodiment, GUI 3000B may include editable text box 3014to enable the user to provide a field name of the field defined by theextraction rule. As described above, the extraction rule may have beenautomatically generated based on user selected text from an event recordin the event records 3008. In other embodiments, a user may havemanually entered the extraction rule. As illustrated, the extractionrule may be displayed in editable text box 3012. Editable text box 3012may enable a user to manually edit the extraction rule. As the user ismanually editing the extraction rule, records 3008 may be automaticallyand dynamically updated in real time to show new values extracted fromeach event record in records 3008. For example, the extracted valuesfrom each event record may be highlighted or otherwise emphasized, asshown by highlight 3024. Additionally, extracted values 3010 may beautomatically and dynamically updated in real time as the user edits theextraction rule.

In other embodiments, the extraction rule may be manipulated byindicating an incorrect extracted value (e.g., a counter-example). In atleast one embodiment, a counter-example may be a value extracted from anevent record based on an extraction rule that does not match a desiredfield of the user. For example, assume an extraction rule is created todefine a field for a server name. However, assume the extraction ruleextracts other data from at least one of the event records. The user mayindicate this other data as a counter-example, and the system mayautomatically re-generate the extraction rule taking thiscounter-example into account. In at least one of various embodiments, auser may indicate a counter-example by clicking on a counter-examplebutton, such as button 3022. By clicking button 3022, the system mayautomatically re-generate the extraction rule based on the counterexample and the other extracted values.

Extracted values 3010 may include one or more unique values extractedfrom records 3008 based on the extraction rule. In at least oneembodiment, statistics that correspond to each unique extracted valuemay be displayed. For example, data 3016 shows a percentage of thenumber of times each particular unique value is extracted from records3008. As illustrated, each of these percentages may also be illustratedas a percentage bar (e.g., percentage bar 3018) for each uniqueextracted value.

FIG. 30C illustrates a non-exhaustive example of a use case of anembodiment of graphical user interface that may be employed to enable auser to select an extracted value to filter the event records. GUI 3000Cmay be an embodiment of GUI 3000A of FIG. 30A.

In at least one embodiment, a user may click on one or more valueswithin extracted values 3010, such as value 3020 to filter records 3008.Records 3008 may display those event records that include an extractedvalue that matches selected value 3020. As illustrated, the display ofextracted values 3010 may be modified to indicate which value wasselected by the user, such as by emphasizing the selected value and/orde-emphasizing the non-selected values.

FIG. 31 illustrates a non-exhaustive example of a use case of anembodiment of graphical user interface that may be employed to displayevent records with an emphasis of fields defined by previously providedextraction rules. GUI 3100 may be an embodiment of GUI 3000A of FIG.30A.

GUI 3100 may include input 3126. Input 3126 may be a check box or othermechanism that may be selected by a user. In at least one embodiment, aselection of input 3126 may display records 3108 with emphasized fieldsdefined by previous extraction rules. As illustrated, each event recordin records 3108 may include one or more emphasized sections of text,such as sections 3128 and 3130. In some embodiments, an emphasizedsection, such as section 3130, may include a plurality of at leastpartially overlapping fields. As shown, these overlapping fields may notbe distinguished from one another. However, in other embodiments (notshown), these overlapping fields may be distinguished from one anotherusing different types of emphasis.

FIGS. 32A-32B illustrate non-exhaustive examples of a use case ofembodiments of a graphical user interface, such as depicted in FIGS.30A-30C, to display extraction rules and/or fields associated with aselected portion of an event record.

GUI 3200A may be an embodiment of GUI 3000C. As illustrated, a user maymove a cursor or other pointer over section 3204 to select section 3204.By selecting section 3204, GUI 3200A may display extraction rulesassociated with that portion of event record 3220. 32By employingembodiments described above, a box 3206 may pop-up and/or open todisplay an extraction rule that is associated with section 3204 of eventrecord 3220. In this example, box 3206 may include a fieldname of afield defined by the associated extraction rule (“Server ID”) and avalue extracted from event record 3220 using the associated extractionrule (“23629”). In this illustration section 3204 may be associated witha single extraction rule.

GUI 3200B may be an embodiment of GUI 3200A. As illustrated, a user maymove a cursor or other pointer over section 3210 to select section 3210.By selecting section 3210, GUI 3200B may display extraction rulesassociated with that portion of event record 3220. In at least oneembodiment, section 3210 may be an embodiment of section 830 of FIG.30C. By employing embodiments described above, box 3212 may pop-upand/or open to display extraction rules that are associated with section3210 of event record 3220. In some embodiments, box 3212 may be anembodiment of box 3206 of FIG. 32A. In this example, box 3212 mayinclude a fieldname of a field defined by each associated extractionrule and corresponding value extracted from event record 3220 using theassociated extraction rules. In this example illustration, section 3210may have three different extraction rules associated with it, and anidentifier of each extraction rule may be displayed in box 3212 (e.g.,“Error”, “Error type”, and “User ID”). Additionally, each associatedextraction rule may be used to extract a corresponding value from eventrecord 3220, which may also be displayed in box 3212.

Moreover, some fields may be sub-fields of other fields. In thisexample, fieldnames “Error type” and “User ID” may be sub-fields offieldname “Error” because fieldname “Error” overlaps both fieldname“Error type” and “User ID”.

FIGS. 33A-33B illustrate a use case example of a real time display of anevent record based on manual editing of an extraction rule. Example3300A illustrates extraction rule 3302 and event record 3304. Value 3306may be highlighted, or otherwise emphasized, as a value extracted fromevent record 3304 based on extraction rule 3302. Example 3300B alsoillustrates extraction rule 3302 and event record 3304. However, asillustrated, extraction rule 3302 may be manually edited by a user.Based on this edited extraction rule, value 3308 may be highlighted as anew value extracted from event record 3304 based on extraction rule3302.

The operation of certain aspects of the technology disclosed will now bedescribed with respect to FIG. 34. FIG. 34 illustrates a logical flowdiagram generally showing one embodiment of an overview process foridentifying one or more locations within an event record with splitabletimestamp information. Process 3400 of FIG. 34 may be implemented withinone or more client devices, blade server, and/or network device.

Process 3400 begins, after a start block, at block 3402, where aplurality of event records are received, and one or more of the eventrecords are displayed using a graphical user interface (GUI). The GUImay be implemented using any of a variety of mechanisms, and is notconstrained to any particular mechanism for displaying the one or moreevent records. In some embodiments, the GUI may be displayed to a userof a client device. However, the GUI may also be configured to bedisplayed using any of a variety of other devices as well. Moreover, thedisplay of the one or more event records may use any of a variety offormats and/or arrangements. For example, event records may be displayedin a table format having rows and columns. In such a display, each eventrecord displayed might be a displayed row, while fields or locationswithin the event record are columns. In other embodiments, each eventrecord displayed might be a column, while fields or locations within theevent records are rows. As discussed further below, other arrangementsmay also be used.

Process 3400 then flows to block 3404, where the GUI also displays asplitable timestamp selector. The splitable timestamp selector might berepresented as a pull down menu structure, a push button, a drag/dropselector, or any of a variety of other selector mechanisms, including acombination of one or more selector mechanisms. The splitable timestampselector is configured to allow the user to identify locations within adisplayed event record having portions of time information for which theuser may select. For example, one location of the event record mightinclude month/day/year information, while another location within theevent record might include day of the week information, time of dayinformation, or so forth. Clearly, an event record might includelocations that include combinations of such time information, and/orother types of time information. Therefore, subject innovations are notlimited to a particular structure, type, or combination of timeinformation. Virtually any time information may be included for which auser might select.

In one non-limiting example, a user might identify locations within anevent record having time information that is distributed acrossdifferent fields or locations within an event record. For example, onefield or location within an event record might include time of dayinformation in the form of time that is local to a source of the eventrecord, and another location that includes universal time of dayinformation.

Another location of the event record might include, however,month/day/year information. Thus, time information might be distributedacross different locations within an event record. Some of theselocations within the event record however might not include a label,tag, header, or other type of indication that the content includes timeinformation. The user might therefore wish to identify such locations ashaving a particular type of time information. Using the splitabletimestamp selector within the GUI, the user may drag, slide, orotherwise identify and select locations within the event record ashaving time information, and what type of time information. Thesplitable timestamp selector allows the user to split timestampinformation across different locations within the event record.

Process 3400 then moves to block 3406 whereas the user selects locationswith split timestamp information, the splitable timestamp information isassociated with the selected locations. This association may beaccomplished using a variety of mechanisms. For example, a new field,header, tag, label, or the like might be automatically inserted in theevent records, event record headers, or the like, that include the splittimestamp information. However, in other embodiments, information aboutthe selected locations might be inserted into a table, list, indexstructure, or the like, along with the associated split timestampinformation. For example, the location within the event records might beidentified as characters 26-31 and as having time information to beassociated with the split timestamp of Month (2 characters), Day (2characters), and Year (2 characters). Such information may be includedin a table, list, index structure, or the like, that might be maintainedseparately, within another event record, or using any of a variety ofother mechanisms.

Process 3400 flows next to decision block 3408 where a determination ismade whether more splitable timestamp information is to be selected andassociated with locations within the event records. If so, processingflows back to block 3404 to continue until no more selections areperformed. Processing then continues to optional block 3410.

At block 3410, a user may create an extraction rule that includessplitable timestamps within the rule. For example, the user might selectevent records where the MMIDDIYY time information, identified using thesplitable timestamp, is greater than some value. As noted, any of avariety of other extraction criteria may be employed. As such, thesubject innovations are not limited by this example. Proceeding to block3412, the extraction rule having splitable timestamp information is thenused to extract event records that satisfy the extraction rule.Continuing to block 3414, any of a variety of analyses might then beperformed on the extracted event records.

Process 3400 then flows to decision block 3416, where a determination ismade whether to continue identifying and selecting locations withinevent records with splitable timestamp information. If so, processingbranches back to block 3404; otherwise, processing may return to acalling process.

FIGS. 35A-C illustrate various non-limiting, non-exhaustive graphicaluser interfaces usable for identifying/selecting one or more locationswithin event records with splitable timestamp information.

GUIs 3500A-C of FIGS. 35A-C are directed towards providing examples ofGUIs that may be used to display one or more event records and to selectlocations within the event records as having time information. The GUIsfurther display a splitable timestamp selector that may be used toselect locations within the event records as having time information.The splitable timestamp selector may be used to identify the type oftime information within the selected location. This splitable timestampinformation may then be associated with the selected locations asdiscussed above.

GUI 3500A of FIG. 35A illustrates event records 3512-3514, withinsection 3508A. Other sections within GUI 3500A may also be displayed,including, data source 3502, which indicates a source of the eventrecords; extraction rule preview 3504, which may be used to create anextraction rule, and input 3506 usable to enable the user to define aspecific filter to apply to the event records (e.g., the user may filterthe event records to display those event records that were recorded on aparticular day). In other embodiments, input 3506 may also enable a userto select how the event records are displayed.

As is further shown in FIG. 35A, event records 3512-3514 are displayedin a ‘by row’ format, where each row represents one event record. Also,shown as columns are locations 3530-3537 for each of event records3512-3514. Where tags, labels, or field headers are available, they arefurther illustrated in row 3510.

Splittable timestamp selector 3520 is shown in FIG. 35A, havingselection arrows that may be employed to select split time information.Splittable timestamp selector 3520 may be clicked on, dragged, orotherwise moved, relocated over one or more columns/locations of thedisplayed event records 3512-3514 to select a location having timeinformation. The selection arrows may be used to select a split time forthe selected location. In one non-limiting, non-exhaustive example, auser might drag splitable timestamp selector 3520 over location 3531 andemploy the selection arrows to identify that location 3531 hasmonth/day/year (MM/DD/YY) time information. A result of such actions isshown as splitable timestamp selection 3521. Similar actions may berepeated, resulting in splitable timestamp selection 3522 showinglocation 3533 having time of day, in Zulu time; and splitable timestampselection 3523 showing location 3536 having weekday time information.Thus, using GUI 3500A, the user may employ splitable timestamp selector3520 multiple times, to select multiple locations within the displayedevent records as having split time information. However, in otherembodiments, splitable timestamp selection 3521 might be dragged toanother location to enable splitting of, for example, the MM/DD/YY timeinformation. Thus, in some embodiments, a user might split the MM/DD/YYtime information across two or more locations, such as MM for onelocation, DD for another location, and YY for still another location.Similarly, splitable timestamp selection 3522 might also be furthersplit. Thus, in some embodiments, the splitable timestamp selection 3522might be dragged over multiple locations, with selections made usingsplitable timestamp selection 3522 as sort of an extension of splitabletimestamp selector 3520. Thus, in this manner, designating splits oftime across locations within event records may be performed in a varietyof ways.

It should be clear that any of a variety of other locations, and/orsplit time information may be selected. For example, in one embodiment,splitable timestamp selector 3520 might allow a user to select to entera definition of split time for locations. That is, in some embodiments,the user might define a unique splitting of time, or even a previouslyundefined timestamp designation. Moreover, in some embodiments, when alocation within the displayed event records is selected, an associationis made between the split time information and the selected location toindicate that the selection location has time information as indicatedby the selected identifier (e.g., MM/DD/YY, time of day: Zulu, orweekday). Moreover, it should be understood that such associationbetween the split time information and the location might be appliedover a plurality of event records, including those event records thatare displayed, or alternatively, over a subset of event records, such asevent records extracted from the plurality of event records based on anextraction rule, or the like. In any event, the splitabletimestamp/location associations may then be used to perform any of avariety of operations upon the event records.

As noted above, subject innovations are not limited by how an eventrecord, event record locations, and splitable timestamp information isdisplayed, Thus, while FIG. 35A illustrates event records 3512-3514 inrows, and columns as locations/fields within the event records, otherarrangements may be used. For example, in some embodiments, eventrecords might be displayed in columns, while locations/fields with theevent records might be displayed in rows. Splitable timestampinformation may then be displayed in a column, and aligned withrespectively selected locations/rows within the event records.

For example, some data might have event records with too many extractedfields to readily display as columns. Therefore, in some embodiments,the fields of each event record might be displayed with one field perrow for each event record, and then displaying event records one underanother. A similar concept might include moving the splitable timestampinformation between fields to indicate the one from which a timestampmight be extracted, or otherwise selected; however, in this instance thetimestamp (or portions thereof) might move up or down between the fieldsrather than across columns.

FIG. 35B shows still another non-limiting, non-exhaustive arrangement ofevent records, locations/fields within event records, and how splitabletimestamp information might be displayed. In this example, GUI 3500Bshows portions of event records 3512-3513. The event records are shownin a single column, one event record below another event record. Shownfor event record 3512 are locations 3531A and 3533A, while at leastlocation 3531B of event record 3513 is displayed. A scrolling tool isshown next to each event record, allowing scrolling within each eventrecord, to display respective locations/fields within an event record.Moreover a global scrolling tool is shown that allows for scrolling overthe event records. Splitable timestamp selector 3520 may again be usedto select locations within the displayed event records as having timeinformation, as discussed above. Thus, as shown, FIG. 35B shows resultsof a selection of field/location 3531A as having split time informationof MMDDYY, as shown by splitable timestamp selection 3521A. In someembodiments, such selection in one event record may be automaticallyreflected within other event records. Thus, in some embodiments,splitable timestamp selection 3521B might automatically be displayed toreflect selections of a similar field/location within another eventrecord based one selection. Also shown is splitable timestamp selection3522A for location 3533A of event record 3512. While not displayed, asimilar automatic selection might occur for event record 3513, and/orother event records.

FIG. 35C illustrates still another non-limiting, non-exhaustivearrangement of event records, locations/fields within event records, andhow splitable timestamp information might be displayed. In this example,GUI 3500C, event records are again displayed in row format, as in 3512A,3513A, and so forth. However, a separate row is also shown forfields/locations selected as having time information. Thus, as shown row3541 illustrates that field 1 (location 3531) of the event records3512-3513 (as displayed by event records 3512A and 3513A) has timeinformation as shown by splitable timestamp selection 3521. Similarly,row 3541 also shows that field 3 (location 3533) of the event records3512-3513 (and displayed as event records 3512B and 3513B) has timeinformation as shown by splitable timestamp selection 3522. In thisexample, then, GUI 3500C might display multiple instances of an eventrecord, as rows, with other rows indicating which field/location withinthe event records are selected using the splitable timestamp selector3520.

Other arrangements or structures, formats, or the like, may be used todisplay within a GUI event records and locations within the eventrecords such that a user might select locations having time informationusing a splitable timestamp selector. Thus, embodiments should not beconstrued as being limited by any particular arrangement of eventrecords, type of splitable timestamp selectors, or mechanisms used toselect locations within event records.

Particular Embodiments

In one implementation, a method is described that accessing in memory aset of events each event identified by an associated time stamp. Eachevent in the set of events includes a portion of raw data from machinedata. The method further includes causing display of or transmitting fordisplay a first user interface including a plurality of events andreceiving data indicating selection of a first event from among theplurality of events. The method also includes transmitting for display asecond user interface presenting the first event to be used to definefield extraction and receiving data indicating a selection of one ormore portions of text within the first event to be extracted as one ormore fields. It also includes automatically determining a fieldextraction rule that extracts as one or more values of the one or morefields the respective selections of the portions of text within theevents when the extraction rule is applied to the events. The method caninclude transmitting for display a third user interface including anannotated version of the plurality of events, wherein the annotatedversion indicates the portions of text within the plurality of eventsextracted by the field extraction rule and presenting second event to beused to refine field extraction and receiving further data indicating aselection of at least one portion of text within the second event to beextracted as into at least one of the fields by an updated fieldextraction rule.

This method and other implementations of the technology disclosed caninclude one or more of the following features and/or features describedin connection with additional methods disclosed. In the interest ofconciseness, the combinations of features disclosed in this applicationare not individually enumerated and are not repeated with each base setof features. The reader will understand how features identified in thissection can readily be combined with other sets of base features.

The method can include transmitting in the second user interface one ormore tools that implement user selection of the one or more portions oftext within the first event and naming of the one or more fields.

It can include the second user interface providing tools that implementuser selection of a sampling strategy to determine the events in thedisplay, receiving further data indicating a selection of the samplingstrategy; and resampling and updating the events to be displayed. Twoexamples of sampling strategies are a diverse events sample and a rareevents sample. Diverse resampling include clustering a set of eventsinto multiple clusters, calculating a size of each cluster, andselecting one or more events from each cluster in a set of larger sizeclusters. Rare sampling can include selecting the events from smallersize clusters. This method also can include updating the events to bedisplayed.

Another sampling strategy involves time range sampling, retrieving atleast a sample of events in the selected time range. The method also caninclude updating the events to be displayed.

The method can include the third user interface providing tools toselect the one or more portions of text within the second event for usein updating a field extraction rule. The selected text in the secondexample event can be linked to fields already created.

The third user interface also can provide tools that implement userselection of either events that match the field extraction rule orevents that are non-matches to the field extraction rule. The method caninclude receiving further data indicating a selection of a match ornon-match subset of events and resampling according to the match ornon-match selection. It can include updating the events to be displayed.

The method can, before transmitting the first user interface, includereceiving a search specification that identifies events to be selected,transmitting for display a search response interface in which the eventsare responsive to the search specification. The search responseinterface then includes a user option to initiate formulation of a textextraction rule.

The method can include automatically determining an updated fieldextraction rule that extracts as one or more values of the one or morefields from both the first event and the second event. This can befollowed by transmitting for display a fourth user interface includingan annotated version of the plurality of events Annotations can indicatethe portions of text extracted by the updated field extraction rule fromthe events.

The method can proceed to validation of the extraction rule, includingtransmitting for display a fourth user interface including an annotatedversion of the plurality of events, that indicates the portions of textwithin the events that are extracted by the field extraction rule. Thefourth user interface can provides one or more user controls thatimplement user selection of indicated portions of the text as examplesof text that should not be extracted. The method can include receivingfurther data indicating a selection of one or more examples of text thatshould not be extracted. The method also can include automaticallydetermining an updated field extraction rule that does not extract thetext that should not be extracted.

Another feature the method can include the second user interfaceproviding tools that implement user selection of among the fields,receiving further data indicating a selection of a selected field, andtransmitting data for a frequency display of values of the selectedfield extracted from a sample of the events, wherein the frequencydisplay includes a list of values extracted and for each value in thelist a frequency and an active filter control, wherein the active filtercontrol filters events to be displayed based on a selected value.

The second user interface can provide tools that implement userselection of a particular field among fields for which extraction ruleshave been created, receiving further data indicating a selection of aselected field, and transmitting data for a frequency display of valuesof the selected field extracted from a sample of the events, wherein thefrequency display includes a list of values extracted and for each valuein the list, frequency information and at least one filter control. Themethod also includes receiving further data indicating a selection of aselected value from the list of values extracted and activation of thefilter control, and transmitting data for a filtered display of valuesof the selected field extracted from an event sample filtered by theselected value.

The method can include receiving further data indicating a selection tosave the extraction rule and field names for later use in processingevents. This method can further include incorporating the savedextraction rule and field names in a data model, in a late bindingschema of extraction rules applied at search time.

Another feature the method can include the second user interfaceproviding one or more tools that implement user entry of a filter valueto determine the events in the display. The filter value can be keywordor a key-value pair. This feature further includes receiving indicatingentry the keyword or key-value pair to use in the filter and resamplingaccording to the value entered. The method also can include updating theevents to be displayed.

Other implementations may include a non-transitory computer readablestorage medium storing instructions executable by a processor to performany of the methods described above. Yet another implementation mayinclude a system including memory and one or more processors operable toexecute instructions, stored in the memory, to perform any of themethods described above.

In another implementation, another method is described of accessing inmemory a set of events, each event identified by an associated timestamp. Each event in the set of events includes a portion of raw datafrom machine data. The method further includes receiving data indicatingselection of a first event from among a first plurality of events anddata indicating a selection of one or more portions of text within theraw data of the first event to be extracted as one or more fields andautomatically determining an initial extraction rule that extracts theselected portions of text within the first event. The method alsoincludes transmitting for display a first interface providing tools thatimplement user modification of the extraction rule. These tools includeone or more of selecting one or more non-adjoining strings toconcatenate with a selected field, selecting a portion of the selectedfield to be trimmed from the beginning or end of the selected field, orselecting sub-portions of text to extract from within the selectedfield.

As described above, any of the method features described in thisdisclosure are candidates to be combined with this method, especiallythe following features. All of the combinations described by thisdisclosure are not enumerated, in the interest of conciseness. Themethod can positively implement the first, second or third tool optiondescribed above. It can implement the first and second, first and third,or second and third tool options. Or, it can implement all three.

Among its features, the method can include receiving further dataindicating selection of the one or more non-adjoining strings toconcatenate into a concatenated field and updating the field extractionrule to combine the non-adjoining strings into the concatenated field.

Similarly, the method can include receiving further data indicating oneor more trim commands to apply to the selected field and updating thefield extraction rule to include the trim commands.

Also, the method can include receiving further data indicating selectionof sub-portions of text to extract from within the selected field,automatically determining a secondary extraction rule to extract thesub-portions of text from within the selected field and updating thefield extraction rule to include the secondary extraction rule.

As with the earlier implementation, another feature can include causingdisplay of or transmitting for display a second user interface providingtools that implement user selection of a sampling strategy to determinethe events in a display, receiving further data indicating a selectionof the sampling strategy, sampling the events to be displayed, andtransmitting for display a third user interface including an annotatedversion of the plurality of events, wherein the annotated versionindicates the portions of text within the plurality of events extractedby the initial extraction rule. Any of the sampling strategies describedin the context of the prior implementation can be combined with thisimplementation.

The method can further include receiving further data indicating aselection to validate the extraction rule and transmitting for display asecond user interface including an annotated version of the plurality ofevents, wherein the annotated version indicates the portions of textwithin the plurality of events extracted by the field extraction ruleand provides one or more user controls that implement user selection ofindicated portions of the text as examples of text that should not beextracted. Responsive to the second user interface, the method caninclude receiving further data indicating a selection of one or moreexamples of text that should not be extracted and automaticallydetermining an updated field extraction rule that does not extract thetext that should not be extracted.

Another feature can include transmitting for display a second userinterface providing tools that implements user selection among thefields, receiving further data indicating a selection of a selectedfield, and transmitting data for a frequency display of values of theselected field extracted from a sample of the events, wherein thefrequency display includes a list of values extracted and for each valuein the list a frequency and an active filter control, wherein the activefilter control filters events to be displayed based on a selected value.

A further feature can include receiving further data indicating aselection to save the extraction rule and field names for later use inprocessing events and incorporating the saved extraction rule and fieldnames in a data model that includes a late binding schema of extractionrules applied at search time.

The method can be extended by transmitting for display a second userinterface providing one or more tools that implement user entry of afilter value to determine the events in the display, receiving furtherdata indicating entry of a keyword value to apply as a filter,resampling according to the keyword value, and updating the events to bedisplayed.

Other implementations may include a non-transitory computer readablestorage medium storing instructions executable by a processor to performany of the methods described above. Yet another implementation mayinclude a system including memory and one or more processors operable toexecute instructions, stored in the memory, to perform any of themethods described above.

The above specification, examples, and data provide a completedescription of the composition, manufacture, and use of the technologydisclosed. Since many embodiments of the technology disclosed can bemade without departing from the spirit and scope of the technologydisclosed, the technology disclosed resides in the claims hereinafterappended.

The invenyion claimed is:
 1. A computer-implemented method comprising:accessing in memory a set of events, each event identified by anassociated time stamp; wherein each event in the set of events includesa portion of raw data; receiving data indicating selection of a firstevent from among a first plurality of events and data indicating aselection of one or more portions of text within the raw data of thefirst event to be extracted as one or more fields; automaticallydetermining an initial extraction rule that extracts the selectedportions of text within the first event; causing display of a firstinterface providing tools that implement user modification of theextraction rule, including selecting a field from the one or more fieldsand: selecting one or more non-adjoining strings to concatenate with theselected field; selecting a portion of the selected field to be trimmedfrom the beginning or end of the selected field; or selectingsub-portions of text to extract from within the selected field.
 2. Themethod of claim 1, further including: receiving further data indicatingselection of the one or more non-adjoining strings to concatenate into aconcatenated field; and updating the field extraction rule to combinethe non-adjoining strings into the concatenated field.
 3. The method ofclaim 1, further including: receiving further data indicating one ormore trim commands to apply to the selected field; and updating thefield extraction rule to include the trim commands.
 4. The method ofclaim 1, further including: receiving further data indicating selectionof sub-portions of text to extract from within the selected field;automatically determining a secondary extraction rule to extract thesub-portions of text from within the selected field; and updating thefield extraction rule to include the secondary extraction rule.
 5. Themethod of claim 1, further including: transmitting for display a seconduser interface providing tools that implement user selection of asampling strategy to determine the events in a display; receivingfurther data indicating a selection of the sampling strategy; samplingthe events to be displayed; and transmitting for display a third userinterface including an annotated version of the plurality of events,wherein the annotated version indicates the portions of text within theplurality of events extracted by the initial extraction rule.
 6. Themethod of claim 1, further including: causing display of a second userinterface providing tools that implement user selection of only eventsthat match the field extraction rule the field extraction rule;receiving further data indicating a selection of only the events thatmatch; and sampling according to the match selection; and causingdisplay of a third user interface including the plurality of eventsaccording to the match selection, wherein the annotated versionindicates the portions of text within the plurality of events extractedby the initial extraction rule.
 7. The method of claim 1, furtherincluding: receiving further data indicating a selection to validate theextraction rule; causing display of a second user interface including anannotated version of the plurality of events, wherein the annotatedversion indicates the portions of text within the plurality of eventsextracted by the field extraction rule and provides one or more usercontrols that implement user selection of indicated portions of the textas examples of text that should not be extracted; receiving further dataindicating a selection of one or more examples of text that should notbe extracted; and automatically determining an updated field extractionrule that does not extract the text that should not be extracted.
 8. Themethod of claim 1, further including: causing display of a second userinterface providing tools that implements user selection among thefields; receiving further data indicating a selection of a selectedfield; and causing display of a frequency table of values of theselected field extracted from a sample of the events, wherein thefrequency table includes a list of values extracted and for each valuein the list a frequency and an active filter control, wherein the activefilter control filters events to be displayed based on a selected value.9. The method of claim 1, further including: receiving further dataindicating a selection to save the extraction rule and field names forlater use in processing events; and incorporating the saved extractionrule and field names in a data model that includes a late binding schemaof extraction rules applied at search time.
 10. The method of claim 1,further including: causing display of a second user interface providingone or more tools that implement user entry of a filter value todetermine the events in the display; receiving further data indicatingentry of a keyword value to apply as a filter; resampling according tothe keyword value; and updating the events to be displayed.
 11. Acomputer-implemented system comprising: a processor, memory coupled tothe processor, and instructions stored in the memory that implement theactions of: accessing in memory a set of events, each event identifiedby an associated time stamp; wherein each event in the set of eventsincludes a portion of raw data from machine data; receiving dataindicating selection of a first event from among a first plurality ofevents and data indicating a selection of one or more portions of textwithin the raw data of the first event to be extracted as one or morefields; automatically determining an initial extraction rule thatextracts the selected portions of text within the first event; causingdisplay of a first interface providing tools that implement usermodification of the extraction rule, including selecting a field fromthe one or more fields and: selecting one or more non-adjoining stringsto concatenate with the selected field; selecting a portion of theselected field to be trimmed from the beginning or end of the selectedfield; or selecting sub-portions of text to extract from within theselected field.
 12. The computer-implemented system of claim 11, furtherincluding: receiving further data indicating selection of the one ormore non-adjoining strings to concatenate into a concatenated field; andupdating the field extraction rule to combine the non-adjoining stringsinto the concatenated field.
 13. The computer-implemented system ofclaim 11, further including: receiving further data indicating one ormore trim commands to apply to the selected field; and updating thefield extraction rule to include the trim commands.
 14. Thecomputer-implemented system of claim 11, further including: receivingfurther data indicating selection of sub-portions of text to extractfrom within the selected field; automatically determining a secondaryextraction rule to extract the sub-portions of text from within theselected field; and updating the field extraction rule to include thesecondary extraction rule.
 15. The computer-implemented system of claim11, further including: causing display of a second user interfaceproviding tools that implement user selection of a sampling strategy todetermine the events in a display; receiving further data indicating aselection of the sampling strategy; sampling the events to be displayed;and causing display of a third user interface including an annotatedversion of the plurality of events, wherein the annotated versionindicates the portions of text within the plurality of events extractedby the initial extraction rule.
 16. The computer-implemented system ofclaim 11, further including: causing display of a second user interfaceproviding tools that implement user selection of only events that matchthe field extraction rule the field extraction rule; receiving furtherdata indicating a selection of only the events that match; and samplingaccording to the match selection; and causing display of a third userinterface including the plurality of events according to the matchselection, wherein the annotated version indicates the portions of textwithin the plurality of events extracted by the initial extraction rule.17. The computer-implemented system of claim 11, further including:receiving further data indicating a selection to validate the extractionrule; causing display of a second user interface including an annotatedversion of the plurality of events, wherein the annotated versionindicates the portions of text within the plurality of events extractedby the field extraction rule and provides one or more user controls thatimplement user selection of indicated portions of the text as examplesof text that should not be extracted; receiving further data indicatinga selection of one or more examples of text that should not beextracted; and automatically determining an updated field extractionrule that does not extract the text that should not be extracted. 18.The computer-implemented system of claim 11, further including: causingdisplay of a second user interface providing tools that implement userselection among the fields; receiving further data indicating aselection of a selected field; and causing display of a frequency tableof values of the selected field extracted from a sample of the events,wherein the frequency table includes a list of values extracted and foreach value in the list a frequency and an active filter control, whereinthe active filter control filters events to be displayed based on aselected value.
 19. The computer-implemented system of claim 11, furtherincluding: receiving further data indicating a selection to save theextraction rule and field names for later use in processing events; andincorporating the saved extraction rule and field names in a data modelthat includes a late binding schema of extraction rules applied atsearch time.
 20. The computer-implemented system of claim 11, furtherincluding: causing display of a second user interface providing one ormore tools that implement user entry of a filter value to determine theevents in the display; receiving further data indicating entry of akeyword value to apply as a filter; and resampling according to thekeyword value; and updating the events to be displayed.
 21. A tangiblecomputer-readable memory having instructions stored in the memory thatimplement the actions including: accessing in memory a set of events,each event identified by an associated time stamp; wherein each event inthe set of events includes a portion of raw data from machine data;receiving data indicating selection of a first event from among a firstplurality of events and data indicating a selection of one or moreportions of text within the raw data of the first event to be extractedas one or more fields; automatically determining an initial extractionrule that extracts the selected portions of text within the first event;causing display of a first interface providing tools that implement usermodification of the extraction rule, including selecting a field fromthe one or more fields and: selecting one or more non-adjoining stringsto concatenate with the selected field; selecting a portion of theselected field to be trimmed from the beginning or end of the selectedfield; or selecting sub-portions of text to extract from within theselected field.
 22. The tangible computer-readable memory of claim 21,further including: receiving further data indicating selection of theone or more non-adjoining strings to concatenate into a concatenatedfield; and updating the field extraction rule to combine thenon-adjoining strings into the concatenated field.
 23. The tangiblecomputer-readable memory of claim 21, further including: receivingfurther data indicating one or more trim commands to apply to theselected field; and updating the field extraction rule to include thetrim commands.
 24. The tangible computer-readable memory of claim 21,further including: receiving further data indicating selection ofsub-portions of text to extract from within the selected field;automatically determining a secondary extraction rule to extract thesub-portions of text from within the selected field; and updating thefield extraction rule to include the secondary extraction rule.
 25. Thetangible computer-readable memory of claim 21, further including:causing display of a second user interface providing tools thatimplement user selection of a sampling strategy to determine the eventsin a display; receiving further data indicating a selection of thesampling strategy; sampling the events to be displayed; and causingdisplay of a third user interface including an annotated version of theplurality of events, wherein the annotated version indicates theportions of text within the plurality of events extracted by the initialextraction rule.
 26. The tangible computer-readable memory of claim 21,further including: causing display of a second user interface providingtools that implement user selection of only events that match the fieldextraction rule the field extraction rule; receiving further dataindicating a selection of only the events that match; and samplingaccording to the match selection; and causing display of a third userinterface including the plurality of events according to the matchselection, wherein the annotated version indicates the portions of textwithin the plurality of events extracted by the initial extraction rule.27. The tangible computer-readable memory of claim 21, furtherincluding: receiving further data indicating a selection to validate theextraction rule; causing display of a second user interface including anannotated version of the plurality of events, wherein the annotatedversion indicates the portions of text within the plurality of eventsextracted by the field extraction rule and provides one or more usercontrols that implement user selection of indicated portions of the textas examples of text that should not be extracted; receiving further dataindicating a selection of one or more examples of text that should notbe extracted; and automatically determining an updated field extractionrule that does not extract the text that should not be extracted. 28.The tangible computer-readable memory of claim 21, further including:causing display of a second user interface providing tools thatimplement user selection among the fields; receiving further dataindicating a selection of a selected field; and causing display of afrequency table of values of the selected field extracted from a sampleof the events, wherein the frequency table includes a list of valuesextracted and for each value in the list a frequency and an activefilter control, wherein the active filter control filters events to bedisplayed based on a selected value.
 29. The tangible computer-readablememory of claim 21, further including: receiving further data indicatinga selection to save the extraction rule and field names for later use inprocessing events; and incorporating the saved extraction rule and fieldnames in a data model that includes a late binding schema of extractionrules applied at search time.